| povbot | /svn/commits: * srichter committed revision 4853: | 00:44 |
|---|---|---|
| povbot | /svn/commits: Grammar fixed. | 00:44 |
| povbot | /svn/commits: * srichter committed revision 4854: | 00:45 |
| povbot | /svn/commits: Converted tests to testbrowser. I think I am done now; it's getting too boring. | 00:46 |
| *** tvon has quit IRC | 01:00 | |
| *** tvon has joined #schooltool | 01:01 | |
| *** tiredbones has quit IRC | 01:17 | |
| *** alga has quit IRC | 03:18 | |
| *** tvon has quit IRC | 09:35 | |
| *** tvon has joined #schooltool | 10:09 | |
| *** th1a has joined #schooltool | 13:34 | |
| srichter | okay, I am here now :-) | 14:21 |
| th1a | Okay, I am sitting outside of POV again. | 14:22 |
| srichter | LOL | 14:23 |
| *** alga has joined #SchoolTool | 14:32 | |
| *** ignas has joined #schooltool | 14:32 | |
| *** alga has quit IRC | 14:53 | |
| *** alga has joined #SchoolTool | 14:56 | |
| *** bskahan has joined #schooltool | 15:07 | |
| th1a | srichter: alga and mgedmin aren't here yet. | 15:29 |
| srichter | ok | 15:29 |
| bskahan | morning | 15:30 |
| bskahan | (or afternoon) | 15:31 |
| th1a | Good morning. | 15:31 |
| bskahan | sorry I missed monday's meeting, didn't realize it was happening | 15:31 |
| th1a | bskahan: Did you get that email to the guy at The Neighborhood School that I cc:ed you on? | 15:31 |
| bskahan | th1a: yes, I looked up his school, its an elementary school in the village/lower east side | 15:32 |
| th1a | bskahan: It is ok. I wasn't online Fri.-Sun. and I didn't think to send out an announcement on Thursday. | 15:32 |
| th1a | Yeah. You should send him an email. I heard back from him shortly thereafter, and he had just found out that their lab had been broken into and an undetermined amount of stuff was stolen. So that sorta pushed ST deployment off his plate. | 15:32 |
| bskahan | eek | 15:33 |
| bskahan | ok | 15:33 |
| *** alga has quit IRC | 15:36 | |
| th1a | I suppose I should try to call alga... | 15:38 |
| th1a | In other news, Helen reports that the meeting in San Francisco went quite well. | 15:38 |
| th1a | The others will be here in about five minutes. | 15:39 |
| srichter | th1a: so what came out of the meeting? | 15:39 |
| th1a | Uh... plans for more meetings! | 15:40 |
| th1a | What else comes out of meetings? | 15:40 |
| srichter | he he | 15:40 |
| th1a | Seriously, though, nothing definite. | 15:40 |
| srichter | I thought something concrete | 15:40 |
| srichter | something that lets us evaluate our position in the market | 15:41 |
| *** tvon has quit IRC | 15:41 | |
| srichter | or the chances of getting aone ;-) | 15:41 |
| th1a | This was the first time any of the actors had gotten together to discuss things in depth, so nobody was expecting anything concrete. | 15:41 |
| th1a | Well, let's put it this way. The Stupski Foundation is going to make a decision about whether or not they're going to go ahead with their plans. | 15:42 |
| th1a | And if so, we'll have to start thinking about how this project might be governed to incorporate more than one Foundation. | 15:43 |
| srichter | I see | 15:43 |
| th1a | They're expecting to make a decision in about two weeks. | 15:43 |
| srichter | are they particularly looking at SchoolTool? | 15:43 |
| th1a | Yep. | 15:44 |
| srichter | interesting | 15:44 |
| th1a | I'm going to get a coke. alga and mgedmin just arrived. | 15:44 |
| th1a | There's no real oss competition. | 15:44 |
| srichter | cool | 15:44 |
| *** mgedmin has joined #schooltool | 15:44 | |
| *** alga has joined #SchoolTool | 15:50 | |
| th1a | OK... | 15:52 |
| th1a | So I figure we should discuss this stuff briefly on IRC to get input from those of us who aren't here physically, about a half hour. | 15:53 |
| th1a | And the we'll draft the proposal offline, since I have taken the trouble of actually coming to Lithuania. | 15:53 |
| srichter | ok | 15:54 |
| th1a | So, let's go over the points of my very rough update of the previous proposal. | 15:54 |
| th1a | Stephan has taken care of the code rearranging. | 15:55 |
| th1a | Is there anything outstanding that will need to be done to finish that task? | 15:55 |
| th1a | Other than reviewing the work? | 15:55 |
| th1a | And making it the new trunk? | 15:55 |
| mgedmin | question: are all the bugfixes in the trunk merged to the branch? | 15:55 |
| srichter | I am currently writing an evolution script | 15:56 |
| srichter | no, not yet | 15:56 |
| srichter | (it was not part of my proposal, but once I am done with the evolution script, I am planning to do this part) | 15:56 |
| srichter | (at leaast as far as I get) | 15:56 |
| th1a | OK. | 15:56 |
| mgedmin | ok, so there are two more outstanding issues: db backwards compatibility & merging all the bugfixes | 15:56 |
| srichter | yes | 15:57 |
| alga | shouldn't we merge Stephan's work to trunk instead? | 15:57 |
| th1a | But after Stephan is done, that pretty much completes the grand reorganization phase. | 15:57 |
| srichter | alga: good luck :-) | 15:57 |
| srichter | th1a: yes | 15:57 |
| srichter | alga: no seriously, too much has been moved | 15:58 |
| alga | so, we're swapping trunk instead? | 15:58 |
| srichter | the trunk has not evolved as much in the mean time | 15:58 |
| ignas | that was the idea | 15:58 |
| alga | ok | 15:58 |
| th1a | That seems prudent. | 15:58 |
| th1a | OK. Next big task: pluggable UI. | 15:58 |
| th1a | What are your thoughts about this srichter? | 15:58 |
| srichter | UI: I did not have time yet to review the pagelet code in the trunk, but: | 15:59 |
| srichter | I looked at it briefly and the examples seem more complex than the simple use cases we need at first | 15:59 |
| srichter | another advantage is that we will have Roger's support if we use this | 15:59 |
| th1a | It seems like we will have to write in some time to make a final evaluation of the available options. | 16:00 |
| srichter | even if we do not like what we see (implementation), we can improve it and Roger will be happy someone contributed | 16:00 |
| alga | I'm all for moving to what's the state of the art in z3 | 16:00 |
| alga | and not reinventing the wheel instead | 16:00 |
| srichter | alga: well, there is none | 16:00 |
| th1a | Well, I think state of the art is in some dispute. | 16:00 |
| srichter | there is the z2ecm stuff, but I talked to ZC people and they say it will not fit our needs well | 16:01 |
| th1a | Any particular reason? | 16:01 |
| srichter | ZC developed their own little system, but it does not cover our use cases either | 16:01 |
| th1a | So it seems likely that pagelets are best? We should start there? | 16:02 |
| srichter | th1a: the z3ecm stuff concentrates more on UI-based skin development | 16:02 |
| srichter | which is based on cpsskin, which might be far too heavy for us | 16:02 |
| srichter | th1a: I think so | 16:02 |
| bskahan | I agree about the z3ecm stuff not working for us | 16:02 |
| th1a | OK. | 16:03 |
| srichter | bskahan: have you looked at the pagelet code some more? | 16:03 |
| bskahan | it's targeted at building an entire UI, not plugging new peices into an existing one | 16:03 |
| bskahan | srichter: yes, I think it meets our needs or comes close enough to be the right place to start | 16:03 |
| srichter | I think we should (a) write down our use cases and (b) see that we write a very minimal example using zope.app.pagelet | 16:03 |
| bskahan | we need pluggbable menus and regions | 16:04 |
| * bskahan nods | 16:04 | |
| th1a | Use cases from the component's point of view? | 16:04 |
| srichter | (b) will serve as documentation for others to use as well | 16:04 |
| bskahan | from the third party developer's point of view | 16:04 |
| srichter | th1a: yeah, basically, what do we want to achieve using pagelets in ST | 16:05 |
| srichter | with concrete examples | 16:05 |
| th1a | OK. We'll work on that in detail. Let's move on for the moment. | 16:05 |
| srichter | and the benefits | 16:05 |
| srichter | ok | 16:05 |
| th1a | Sample data. | 16:05 |
| th1a | It seems like we should be able to use interfaces to generate sample data for components. | 16:06 |
| srichter | oh yeah | 16:06 |
| th1a | To help, at least. | 16:06 |
| srichter | I think we should borrow Jim's layer concepts from tests | 16:07 |
| srichter | you fdefine layers of sample data | 16:07 |
| th1a | I'm getting closer to being able to use correct Z3 jargon... | 16:07 |
| srichter | that might depend on each other | 16:07 |
| srichter | then you can say, I want this and that layer | 16:07 |
| srichter | and packages subscribe to those layers to add content | 16:07 |
| srichter | (or can even create new layers) | 16:08 |
| srichter | thoughts? | 16:08 |
| mgedmin | it looks like it might just work | 16:08 |
| mgedmin | so, a layer would be an interface? | 16:08 |
| mgedmin | registered as an utility? | 16:09 |
| th1a | I was going to say "utility." | 16:09 |
| bskahan | and each new module would provide a layer (and define what other modules it depends on)? | 16:09 |
| mgedmin | and you would register subscribers for (IGenerateSampleDataEvent, some_layer)? | 16:09 |
| srichter | mgedmin: something like that | 16:10 |
| srichter | We just have to handle dependencies | 16:10 |
| srichter | maybe a layer should be a component | 16:10 |
| mgedmin | is there something in Z3 for dependency handling? | 16:10 |
| th1a | What is dependent on what? | 16:10 |
| mgedmin | I remember there used to be some tools for handling dependencies among local components | 16:10 |
| srichter | that keeps track of: the layer interface, dependencies, generate methof | 16:10 |
| mgedmin | th1a, one layer ("sample calendars") might depend on another layer ("sample persons") | 16:11 |
| srichter | mgedmin: right, there is dependency code, but I do not know whether it is suitable here | 16:11 |
| mgedmin | hmm | 16:11 |
| alga | hardcode? | 16:11 |
| th1a | But calendars are dependent on persons anyhow. | 16:11 |
| alga | in the implementation of "sample calendars" call "sample persons", and live with it? | 16:12 |
| th1a | At this point, that seems adequate. | 16:12 |
| mgedmin | I'd be happier if we went from requirements and user interface mockups to implementation details rather than starting with implementation details | 16:12 |
| th1a | We are not, for the next year at least, literally worried about what happens when people remove core pieces of SchoolTool and try to run it. | 16:12 |
| srichter | alga: well, but you might get duplication errors | 16:13 |
| th1a | OK. | 16:13 |
| srichter | unless you want to be able to only generate one layer at a time | 16:13 |
| mgedmin | so, does a user choose what bits of data he wants? | 16:13 |
| mgedmin | when the user generates sample data, what happens to existing data? | 16:13 |
| th1a | Yes, although it doesn't have to be fine grained. | 16:13 |
| mgedmin | is it replaced or supplemented? | 16:13 |
| th1a | This is a development tool. | 16:14 |
| th1a | What would be more useful to you as a developer? | 16:14 |
| srichter | mgedmin: Could we assume the DB is empty? | 16:14 |
| mgedmin | hm... | 16:14 |
| srichter | I think we should :-) | 16:14 |
| srichter | (for now) | 16:14 |
| mgedmin | we can't assume | 16:14 |
| mgedmin | what do we do when it's not empty? | 16:14 |
| srichter | go until you find a conflict and break | 16:15 |
| th1a | I'd say add the sample data. | 16:15 |
| mgedmin | choices: refuse to generate data, clear DB and generate data, do not clear DB and generate data | 16:15 |
| alga | ignore duplicates? | 16:15 |
| th1a | Don't clear the DB. | 16:15 |
| srichter | I agree with Tom that this is a developer tool and does not have to be end user savvy | 16:15 |
| bskahan | "new sample" and "more sample" would be nice | 16:15 |
| mgedmin | "clear all data" might come in useful too | 16:15 |
| alga | "clear all fake data" | 16:15 |
| mgedmin | if we have enough confirmation dialogs to make it hard to accidentally lose data | 16:15 |
| srichter | clear all data == remove Data.fs | 16:15 |
| mgedmin | "clear all fake data" is a bit harder... marker interfaces? | 16:15 |
| th1a | This could be restricted to developer mode. | 16:16 |
| mgedmin | ok, back to ui | 16:16 |
| srichter | mgedmin: I think you are thinking about it too hard | 16:16 |
| mgedmin | so the developer goes to some special developer mode page | 16:16 |
| mgedmin | srichter, so do I :) | 16:16 |
| mgedmin | so the developer goes to some special developer mode page | 16:16 |
| mgedmin | finds "sample data" | 16:16 |
| mgedmin | then checks a few checkboxes? | 16:16 |
| srichter | the point is not to create a end-user capable tool but allow us to put in data wuickly | 16:16 |
| mgedmin | [x] calendars, [x] timetables | 16:16 |
| mgedmin | school size: small|medium|large | 16:17 |
| srichter | yep | 16:17 |
| mgedmin | why do we need checkboxes/layers? | 16:17 |
| mgedmin | why not generate everything that is possible? | 16:17 |
| th1a | Save time? | 16:17 |
| srichter | mgedmin: I thought it was one of your requirement to be able to do this incremental and partial? | 16:18 |
| srichter | I think genreate everything is perfectly fine with me | 16:18 |
| th1a | Sounds ok by me. | 16:18 |
| srichter | (until I hit a use case when it sucks :-) | 16:18 |
| th1a | My use case is that I just want to be able to review the latest code with real-looking data easily. | 16:18 |
| mgedmin | srichter, I think the "incremental" and "partial" bits were not for the user, but for the developer | 16:19 |
| srichter | right, I know | 16:19 |
| th1a | And I want new components to have new data as they are being developed. | 16:19 |
| mgedmin | if I write an ST addon that adds, say, lottery tickets on persons, I want to be able to plug into the sample data generator | 16:19 |
| srichter | I just don't have use cases for now, so its hard to see what we want | 16:19 |
| srichter | yep | 16:19 |
| mgedmin | implementation: | 16:20 |
| mgedmin | I thought a few subscribers might be enough | 16:20 |
| mgedmin | generate sample data for the school | 16:20 |
| mgedmin | then for each person/group/resource we fire "generate sample data for this person/..." | 16:20 |
| mgedmin | etc. | 16:20 |
| th1a | Again, these are mostly third party developer use cases, so we all just have to imagine we're third party developers. Another target user is the school admin who wants to kick SchoolTool's tires easily. | 16:20 |
| srichter | note that subscribers do not have an order, so be very careful here | 16:20 |
| mgedmin | that's why I envisioned an event for every object, so that you only attach things to objects that were already generated | 16:21 |
| mgedmin | instead of traversing and relying on other generators to have created something first | 16:21 |
| srichter | the more I think about it, the more I like your idea of a marker interface | 16:21 |
| th1a | OK. Let's not go deeper into it at this point. | 16:22 |
| th1a | Moving on... | 16:22 |
| srichter | because then we can listen to ObjectAddedEvent and renotify it has (IObjectAddedEvent, IContentComponent, ISampleData) | 16:22 |
| srichter | and then write subscribers for that | 16:22 |
| th1a | CSV import/export needs to be handled more systematically. | 16:23 |
| th1a | Again, it feels to me like we should be able to manage CSV import using interfaces. | 16:23 |
| th1a | Based on schemas. | 16:23 |
| mgedmin | some of it -- yes | 16:23 |
| alga | do you insist on CSV? | 16:23 |
| th1a | In the real world, yes. | 16:24 |
| alga | would the RESTive format dumps be too hard for the user? | 16:24 |
| mgedmin | alga, yes | 16:24 |
| srichter | yes, definitely | 16:24 |
| th1a | Sadly, yes. | 16:24 |
| alga | can we transform CSV into REST? | 16:24 |
| mgedmin | why would we want to? | 16:24 |
| srichter | I think CSV would not provide a full mapping of the data | 16:25 |
| th1a | To feel like the investment in REST is justified... | 16:25 |
| alga | REST is THE serialization | 16:25 |
| th1a | Realistically, schools will be dumping data out of spreadsheets and Excel. | 16:25 |
| alga | CSV is a nice wrapper for the users | 16:25 |
| * srichter will eventually start a discussion on the justification of REST (I still cannot see it) | 16:25 | |
| th1a | srichter: Sorry I brought it up... | 16:26 |
| th1a | Anyhow... | 16:26 |
| srichter | the problem with REST is that there are no high-level editors | 16:26 |
| mgedmin | the reason for REST is that you can write one | 16:26 |
| srichter | having a school admin edit XML is nto an option (and not good for the integrety of the system) | 16:26 |
| th1a | Does it seem practical to make the CSV *importing* more automatic and based off interfaces? | 16:27 |
| mgedmin | alga, re mapping CSV -> REST: one line of CSV is likely to result in several RESTive requests | 16:27 |
| bskahan | excel is pretty much the target client application until someone writes a REST client | 16:27 |
| srichter | mgedmin: right, but this use case is very utopian | 16:27 |
| ignas | srichter, REST is the answer for people that ask - how can i integrate my java thigajamajig with SchoolTool | 16:27 |
| mgedmin | why do it in client side? | 16:27 |
| th1a | Let's NOT discuss REST. | 16:27 |
| * srichter stops | 16:27 | |
| mgedmin | scope of CSV? | 16:27 |
| mgedmin | what is it? | 16:27 |
| srichter | I think we need use cases | 16:27 |
| srichter | one would be the easy upload of users | 16:28 |
| srichter | easy upload of grades | 16:28 |
| th1a | Well, right now we run into cases where we've done CSV import for objects that only cover some attributes. | 16:28 |
| srichter | (I love that blackboard feature) | 16:28 |
| th1a | And pretty quickly we get into "I want to import this other attribute in my CSV." | 16:28 |
| th1a | So should we just let all attributes in an object's schema be imported via CSV? | 16:29 |
| srichter | th1a: it should be very hard (if not impossible) for CSV to mess with the system's integrety, so mapping only "safe" attributes is a good choice | 16:29 |
| mgedmin | th1a, what is "object" here? | 16:29 |
| srichter | object: Person, Group, Resource, ... | 16:29 |
| mgedmin | are we talking just about top-level objects (those stored in top-level containers)? | 16:29 |
| srichter | mgedmin: I would hope so, if not we open a huge can of worms | 16:29 |
| mgedmin | if we go into importing calendar events etc., things get difficult -- so would that be in scope? | 16:30 |
| th1a | Calendar events, no. | 16:30 |
| mgedmin | also, for example, some Person attributes are provided via adapters & annotations | 16:30 |
| mgedmin | I imagine we want to import those | 16:30 |
| srichter | th1a: so maybe we can come up with a compoennt way of doing CSV | 16:30 |
| srichter | using subscribers, similar to the new traverser code | 16:30 |
| mgedmin | hm... | 16:31 |
| srichter | you register things that can be exported for a component | 16:31 |
| srichter | the user then selects the attributes s/he wants in the export | 16:31 |
| mgedmin | I think I like that... | 16:31 |
| mgedmin | I envision something like this: | 16:31 |
| srichter | (this is similar to what blackboard allows you to do for student data, but more flexible) | 16:31 |
| mgedmin | you choose what you want to export (persons/groups/resources/etc) | 16:32 |
| mgedmin | then you get a set of attributes that you can export | 16:32 |
| mgedmin | and you list those (e.g. "id,name,phone,list_of_groups") | 16:32 |
| mgedmin | names could refer to schema fields of the object, or to schema fields of adapters applied to the object | 16:33 |
| mgedmin | we could have some adapters used solely for import/export -- list_of_groups would be one example | 16:33 |
| srichter | yep | 16:33 |
| th1a | Import and export have somewhat different requirements. | 16:33 |
| srichter | slightly OT: I think this brings up a whole new scope to SchoolTool: Application customization on a high-level | 16:33 |
| th1a | For importing we can define fairly simple little csv documents. | 16:34 |
| th1a | For exporting, we need to allow admins to configure big complex dumps according to their specific requirements. | 16:34 |
| th1a | Actually, we should probably not do exporting now. | 16:34 |
| th1a | At least the complex cases. | 16:34 |
| mgedmin | interesting | 16:35 |
| mgedmin | from my point of view it seems that export is easier than import | 16:35 |
| th1a | Safer! | 16:35 |
| srichter | I think the simple format should be a special case of the complex one | 16:35 |
| ignas | what is a complex format ? | 16:35 |
| srichter | basically, for dummy users we do not give them all the power | 16:35 |
| ignas | what is the most complex case we can get in ST at the moment ? | 16:36 |
| srichter | ignas: I would think the very generic mechanism Marius described is complex | 16:36 |
| srichter | ignas: simple would be: Export a grade list of this section | 16:36 |
| th1a | Like, send us all the demographic data for all the student in your school in this exact pattern. | 16:36 |
| srichter | th1a: is this a *real* use case? | 16:37 |
| th1a | YES. | 16:37 |
| mgedmin | sounds simple | 16:37 |
| srichter | th1a: this will almost always require some coding | 16:37 |
| th1a | No child left behind, baby. | 16:37 |
| ignas | so one interface is not wenough i guess ... because some of these things can be stored deeper into an object ... | 16:37 |
| srichter | we will just have to ensure that our framework is flexible enough to handle those cases | 16:37 |
| ignas | like an attribute of an attribute ... | 16:37 |
| th1a | I haven't really looked at these things in detail, but they are the bane of school admin's existence apparently. | 16:37 |
| mgedmin | I hate starting from vague specs | 16:38 |
| th1a | It is just that you have to have an interface or templating language that gets the format just right. | 16:38 |
| ignas | th1a, maybe you could get a few real requests that admins are getting ? | 16:38 |
| srichter | ok, I would not worry about supporting an X complex system, but rather ensure that someone can do it in third party code | 16:38 |
| ignas | so we could use them as a base requirements ... | 16:38 |
| th1a | I think my point is that we don't want to deal with those cases at this point anyhow. | 16:38 |
| th1a | Trying to get back on track. | 16:39 |
| srichter | ok, to sum up: I like Marius' approach to complex cases and if done with the CA it should be flexible enough for all later use cases | 16:39 |
| th1a | Let's just assume that we aren't dealing with the question of difficult formatting. | 16:39 |
| mgedmin | what's difficult formatting? | 16:39 |
| mgedmin | we're talking CSV here | 16:40 |
| mgedmin | one line per object, comma separated strings | 16:40 |
| srichter | mgedmin: for example, if you get a list of groups a student belongs to, how is this list formatted (in a single cell) | 16:40 |
| mgedmin | unless you think we might have a field that is composed from several attributes? | 16:40 |
| th1a | Unwieldy. | 16:40 |
| srichter | do you provide the id, title, both...? | 16:40 |
| mgedmin | e.g. address "$street $number, $city, $whatever"? | 16:40 |
| mgedmin | srichter, we do this now -- we use space separated list of IDs | 16:41 |
| mgedmin | it breaks down when you have spaces in your IDs, obviously | 16:41 |
| srichter | mgedmin: but this might not be the requirement for a particular district | 16:41 |
| mgedmin | that's why I imagine the admin will want to specify the format himself | 16:41 |
| mgedmin | and by "specify the format", the simplest thing that I can imagine is | 16:41 |
| mgedmin | a single line of comma separated field names | 16:42 |
| srichter | so anyways, if we do all this with adapters/subscribers we are safe, because admins can register custom subscribers | 16:42 |
| mgedmin | import format: "id, title, foo, bar, baz" | 16:42 |
| alga | srichter: in theory :-) | 16:42 |
| mgedmin | where we list all available fields somewhere on the page | 16:42 |
| mgedmin | if you have some very complex requirements, you can write an add-in | 16:42 |
| srichter | yep | 16:42 |
| mgedmin | with custom CSV import/export views | 16:42 |
| th1a | Here's what the UK requires when you transfer a student from one school to another: http://www.teachernet.gov.uk/management/tools/ims/cbds/cbdsspecs/ | 16:44 |
| alga | are we trying to support moving students with CSV? | 16:45 |
| srichter | th1a: is CSV import/export such a high priority now? We do not even have a functioning SIS system ;-) | 16:46 |
| srichter | should we not concentrate on getting the data structures into palce first? | 16:46 |
| th1a | Well, I keep trying to say that import is more of an issue than export. | 16:47 |
| th1a | In the immediate term. | 16:47 |
| mgedmin | AFAIU somewhat customizable CSV import/export is a requirement for the April release | 16:47 |
| th1a | But it is a fair question. | 16:47 |
| mgedmin | the exact scope is murky, <whine>as always</whine> | 16:47 |
| th1a | Well, here's the question, then. | 16:48 |
| th1a | Is there a reason to make this a framework level issue, | 16:48 |
| th1a | or continue to have it be handled ad hoc by each add-on package? | 16:48 |
| alga | I have a feeling that you're in the best position to answer this | 16:49 |
| mgedmin | I feel that some framework support is needed | 16:49 |
| srichter | right, me too | 16:49 |
| mgedmin | demographics is a plugin, and I assume we want to import demographics at the same time when we import pupils | 16:50 |
| srichter | we should develop an initial framework and extend it as necessary | 16:50 |
| mgedmin | so one CSV for both core data and add-on data | 16:50 |
| alga | that's a point | 16:50 |
| mgedmin | possibly it is as simple as defining some field names and tying them to an interface/attribute name pair for adaptation and assignment | 16:50 |
| th1a | I wouldn't say having one combined CSV is a requirement. | 16:51 |
| th1a | Basically, when you add a demographics schema, it should be pretty straightforward to make it also importable via CSV. | 16:51 |
| th1a | If it requires a separate file at this point, that's ok. | 16:51 |
| th1a | Anyhow... I think we've beaten this to death, at least as long as we're typing. | 16:52 |
| th1a | Built-in roles. | 16:52 |
| th1a | We need some. | 16:52 |
| mgedmin | what's that? | 16:52 |
| mgedmin | "teacher/pupil/janitor"? | 16:52 |
| th1a | More or less. | 16:53 |
| th1a | I don't think there's anything tricky about it. | 16:53 |
| th1a | But people with fundamentally different roles are going to need to start getting different views. | 16:53 |
| srichter | so here is the tricky question? | 16:54 |
| srichter | Should we implement different roles or different groups? | 16:54 |
| th1a | I guess that is the question. | 16:54 |
| srichter | both, roles and groups, are collections, so we can choose either one | 16:54 |
| srichter | I would prefer groups | 16:55 |
| srichter | because then I can annotate data to it | 16:55 |
| mgedmin | groups. | 16:55 |
| srichter | like the workflow stuff I did | 16:55 |
| th1a | This overlaps with my last little point on my draft about access control based on relationships. | 16:55 |
| alga | groups in ST sense? | 16:55 |
| alga | not the Z3 security policy? | 16:55 |
| th1a | How do we designate that a parent, for example, can see only their child's personal info? | 16:56 |
| th1a | Local role? | 16:56 |
| th1a | Or actually derived from relationships? | 16:56 |
| srichter | local role | 16:56 |
| mgedmin | I saw steve alexander's presentation about the security model they use in launchpad | 16:57 |
| srichter | alga: I was talking about the Group class, which is efectively a Z3 security policy component | 16:57 |
| mgedmin | they use adapters that can grant or deny access according to object type | 16:57 |
| ignas | mgedmin, +1 | 16:57 |
| alga | that's basically defining our own security policy | 16:57 |
| mgedmin | ignas, ditching the standard z3 security policy and rolling our own is a big step | 16:58 |
| mgedmin | maybe it would be good, maybe not, I am not sure | 16:58 |
| mgedmin | now the security is almost completely in the hands of the user | 16:58 |
| alga | We need to have a solid understanding what are the requirements for the security machinery | 16:58 |
| mgedmin | which is flexible, but overwhelming, unintuitive, complex, and probably not very secure | 16:58 |
| ignas | if we want permissions that depend on 2-3 step relationships it might be the most sensible way ... | 16:58 |
| alga | seeing your child's data is just one example | 16:58 |
| srichter | I would be hesitant about implementing our own security policy | 16:59 |
| alga | th1a: do you imagine what are the security/permission models you'd like to see? | 16:59 |
| srichter | just because it is a lot of code to support | 16:59 |
| ignas | like - janitor can see when a resource is not busy if the resource is a location ... | 17:00 |
| th1a | We should probably talk about security offline for a while. | 17:00 |
| srichter | yeah | 17:00 |
| th1a | So... wrapping up for a bit, I would point out that one outcome of this discussion may be to drop some of these things that we can't actually clearly define at this point. | 17:01 |
| mgedmin | srichter, it's not that much code | 17:01 |
| th1a | Which is an OK outcome! | 17:01 |
| mgedmin | the question is, which security policy matches our requirements better | 17:01 |
| mgedmin | and I'm unqualified to answer it, since I do not understand what our security requirements are :( | 17:01 |
| srichter | I think we should change the dev model a bit | 17:02 |
| srichter | we should start developing the data model we need | 17:02 |
| srichter | in the mean time Tom can contact schools and collect real use cases | 17:02 |
| srichter | and then we start working at one requirement at a time | 17:03 |
| srichter | we are doing a lot of guessing on what's needed | 17:03 |
| srichter | for example, I could provide in good deal the requirements from a teacher's and student's perspective in a small university, simply because I am filling both roles at the moment | 17:04 |
| ignas | or maybe reduce the size of iterations ? | 17:04 |
| srichter | ignas: what do you mean? | 17:04 |
| ignas | because well the scope of the proposal is 1 month | 17:04 |
| srichter | oh, I see what you are saying | 17:05 |
| ignas | which with productive enough programmers becomes way to large to estimate without guesswork | 17:05 |
| ignas | without an accurate proposal - we can't divide up the work/ find out what features to cut and etc. | 17:05 |
| *** tiredbones has joined #schooltool | 18:17 | |
| srichter | did you guys know that you recuurence objects are not persistent? | 18:19 |
| mgedmin | yes | 18:20 |
| mgedmin | a long time ago recurrence objects were immutable data values, sort of like strings or datetimes | 18:20 |
| mgedmin | now they aren't, but in any case, they're not supposed to ever be shared between more than one object | 18:21 |
| srichter | as long as they can change, don't they have to be persistent? | 18:22 |
| mgedmin | oops | 18:22 |
| mgedmin | I knew there was at least one more reason I felt uneasy about making them mutable | 18:23 |
| mgedmin | persistency pinging | 18:23 |
| mgedmin | I'm sure that's not a problem right now, but it could easily become one | 18:23 |
| * srichter has to put so much BBB code into this clean ST code :-/ | 18:27 | |
| th1a | BBB? | 18:28 |
| srichter | BBB is a shortcut for backward-compatibility | 18:28 |
| th1a | Ah. | 18:28 |
| srichter | eventually we have to support generic object path aliases | 18:28 |
| srichter | I am going to chat with Tim next week to imlement some support in the ZODB | 18:28 |
| srichter | the hardest part will be to write the evolution script for relationships | 18:31 |
| srichter | other than that I seem to have everything under control | 18:40 |
| srichter | th1a: btw, I am interested int he outcome of the discussion you had | 18:57 |
| th1a | Well, we decided that some kind of relationship-based access control was going to have to be devised, but decided we'd have to let that ferment for a little while before we'd be able to draft a proposal. | 18:58 |
| th1a | I had been hoping to spend more time talking about that two weeks ago but we hadn't gotten to it. | 18:59 |
| th1a | I'm starting to write up some pluggable UI use cases.\ | 18:59 |
| th1a | That's going to be the main part of the proposal. | 18:59 |
| srichter | cool | 19:00 |
| th1a | I think we're going to defer import/export until we do the personal info/demographics stuff, because they make sense together. | 19:00 |
| srichter | ok | 19:00 |
| th1a | BTW... I'm trying to focus on things that don't really require detailed end user use cases. | 19:01 |
| th1a | I want to focus on developer issues. | 19:02 |
| srichter | ok | 19:02 |
| th1a | But it is looking like we'll just defer some of them until they're embedded in more specific end-user functionality. | 19:02 |
| srichter | ok | 19:03 |
| th1a | Anyway... I should shut up and write use cases. | 19:05 |
| th1a | I think that's the consensus :-) | 19:05 |
| srichter | LOL | 19:05 |
| th1a | bskahan: ayt? | 19:38 |
| bskahan | hello | 20:02 |
| bskahan | th1a: was away from the keyboard for a bit | 20:02 |
| th1a | I think I've figured out how I have to can write the pluggability use cases usefully. | 20:03 |
| bskahan | ok | 20:04 |
| bskahan | what are you thinking? | 20:04 |
| th1a | Basically go over the main components that we have to create and roughly what needs to be plugged for that component for the main view of each built in group (teacher, student, clerk, administrator) | 20:04 |
| th1a | And for each application object when viewed directly. | 20:05 |
| th1a | We sort of have a dichotomy between having user dashboards and viewing the objects directly. | 20:05 |
| bskahan | isn't that more of an "adaptable" UI (which I agree we need), vs. a "pluggable" UI (which we also need) | 20:06 |
| bskahan | by adaptable I mean, it sounds like your talking about changing what the user sees based on the users role and possibly context | 20:06 |
| th1a | I think, for example, that it is good that you would be able to navigate to a class and view the assignments for the class, but teachers will actually create those assignments from their main gradebook view. | 20:06 |
| bskahan | vs. pluggable, meaning a third party dev can create a new object on a person and get it added to the menu and rendered sanely in part of a page | 20:07 |
| th1a | Well, I'm bumping up against the realities. | 20:07 |
| bskahan | i think we need both, but I'm not sure they need to be concurrent | 20:08 |
| th1a | What is forming in my mind is that you'll have an adaptable and pluggable dashboard, and some direct views of objects which are just pluggable. | 20:08 |
| * bskahan nods | 20:09 | |
| bskahan | I'd like to replace the default login redirect with that sort of dashboard (in place of the current calendar redirect) | 20:09 |
| th1a | Right. | 20:10 |
| povbot | /svn/commits: * srichter committed revision 4855: | 20:10 |
| srichter | yeah, that's what BlackBoard does | 20:10 |
| povbot | /svn/commits: Add initial cut of backward-compatibility code. We might notice more stuff later, but my fairly comprehensive set of data passed just fine. | 20:10 |
| srichter | BB has a fairly nice overview view | 20:10 |
| bskahan | what would be in the dashboard, as of today? | 20:10 |
| srichter | upcoming events | 20:10 |
| bskahan | (the reason I haven't pushed for it yet is that I think only upcoming events would be there now) | 20:10 |
| bskahan | ;) | 20:10 |
| th1a | I guess the only real option in play is the possibility of deprecating navigating directly to objects almost entirely, which I don't think it is something we'd want to do. | 20:11 |
| bskahan | th1a: I think we definitely want to do that | 20:11 |
| th1a | We do want to deprecate it? | 20:11 |
| th1a | I don't have strong feelings I guess. | 20:12 |
| bskahan | yes, we want the UI to focus on tasks to be accomplished, not "thing to do tasks on" | 20:12 |
| srichter | mmh, I start to think that deprecation might be ok for high-level users | 20:12 |
| srichter | the only people that think in terms of objects, are managers | 20:12 |
| srichter | like: I want to delete this person | 20:13 |
| bskahan | srichter: right | 20:13 |
| th1a | Well, I think that in most cases you would at most want to have a sort of read only view when you're viewing an object directly. | 20:13 |
| th1a | For example, follow a link to a kid, and you get sort of a dashboard for the kid. | 20:13 |
| bskahan | I think in the long term, things liks the current PersonView are of limited value | 20:14 |
| srichter | btw, when I played with ST yesterday I was very impressed with the Timetable Schema wizard and edit screens; we need more of those power views :-) | 20:14 |
| th1a | Or, on kid's page you can click "gradebook" to see grades, "info" to see info, etc. | 20:14 |
| bskahan | right, unless the PersonView pulls in the grades, schedules, notes, etc | 20:14 |
| bskahan | we just don't have alot of those features yet | 20:14 |
| srichter | I wonder whether we should be so location centric | 20:15 |
| th1a | Well, I'm assuming that would be the case. | 20:15 |
| srichter | maybe we should more write views for the principal in the request | 20:15 |
| srichter | I wonder whether we can bend Zope 3 to do this | 20:15 |
| th1a | Well, we've already steadily downplayed navigation/location. | 20:15 |
| * bskahan nods | 20:15 | |
| mgedmin | how is that different from writing views for ISTApplication and using request.principal inside? | 20:16 |
| srichter | mgedmin: the form of the request.principal defines the view | 20:16 |
| srichter | nevermind | 20:17 |
| srichter | it was a stupid idea | 20:17 |
| mgedmin | hmm... the login page can redirect to an appropriate view depending on the principal | 20:17 |
| mgedmin | or the start page | 20:17 |
| mgedmin | (I mean @@index.html for ISTApp) | 20:18 |
| srichter | right | 20:18 |
| srichter | maybe that's the way to approach all of this | 20:18 |
| srichter | take a user and ask: what are those user's common tasks | 20:18 |
| bskahan | or, everyone redirects to a 'dashboard' of sorts, and the dashboard is populated with useful components based on the principal | 20:18 |
| srichter | bskahan: yeah, that's what blackboard does and it works ok | 20:19 |
| th1a | Actually, I don't really want to do a dashboard yet. | 20:19 |
| th1a | Even by April we won't have enough components to make it necessary. | 20:19 |
| * bskahan agrees | 20:19 | |
| th1a | Or if we do that, it will be one of the last things. | 20:19 |
| srichter | I am also thinking that we spread ourselves thin here; currently we are working on a SIS and a course management system | 20:19 |
| bskahan | it should be a last thing | 20:19 |
| bskahan | so that its designed knowing what we can put in it ;) | 20:20 |
| th1a | More accurately, we're doing and SIS and a gradebook. | 20:20 |
| srichter | ok, in that case we can keep the assignments very minimal objects | 20:20 |
| th1a | When I say "creating an assignment" I just mean some metadata. | 20:20 |
| srichter | it is just an entry in the gradebook | 20:20 |
| th1a | Trig quiz, 10 points, September 12, etc. | 20:21 |
| bskahan | and it should create an event in the calendar | 20:21 |
| bskahan | or something event-like | 20:21 |
| srichter | Right, I think we should not worry about the description of the assignment though | 20:21 |
| th1a | Right, so the calendar will be dashboardy. | 20:21 |
| th1a | Well, a description textbox is easy enough. | 20:21 |
| th1a | Just like an event description. | 20:22 |
| bskahan | is the assignment an event-like object (located under a calendar URL) or is it an object located under a Section that is related to a calendar event? | 20:23 |
| srichter | th1a: OT: it would be nice if you could use .txt suffixes for your proposals :-) | 20:23 |
| th1a | Sorry. Mac habits. | 20:23 |
| th1a | Actually, I think I assume it appends it, but it is invisible anyhow, so I don't know. | 20:24 |
| th1a | bskahan: I'd imagine the latter. | 20:27 |
| bskahan | th1a: that's what I thought, just checking | 20:28 |
| bskahan | I'm grabbing lunch, back in 20 minutes or so | 20:40 |
| th1a | OK. I think I will have something useful by tomorrow morning. | 20:41 |
| *** th1a has quit IRC | 20:43 | |
| povbot | /svn/commits: * srichter committed revision 4856: | 21:57 |
| povbot | /svn/commits: Remove in anticipation of merge. | 21:57 |
| srichter | I see that the Zope 3 external is gone from the repository; how are we supposed to get SchoolTool running? | 22:01 |
| srichter | ok, I see | 22:01 |
| srichter | never mind | 22:02 |
| mgedmin | 'make run' ;) | 22:10 |
| bskahan | apt-get install zope-libs ;) | 22:23 |
| *** tvon has joined #schooltool | 22:25 | |
| *** ignas has quit IRC | 22:32 | |
| srichter | mgedmin: I am making progress with the merging... sigh | 23:24 |
| *** bskahan has quit IRC | 23:29 | |
| povbot | /svn/commits: * srichter committed revision 4857: | 23:52 |
| povbot | /svn/commits: Started merging the trunk checkins of schoolbell and schooltool to the branch: | 23:52 |
| povbot | /svn/commits: Merged: 4611, 4616, 4621, 4633, 4640, 4650, 4652, 4653, 4654, 4655, 4659, | 23:52 |
| povbot | /svn/commits: 4660, 4664, 4674, 4678, 4679, 4680, 4682, 4683, 4684, 4685, 4686, 4687, 4688, 4689, 4690, 4693, 4694, 4695, 4696, 4697, 4698, 4699, 4700, 4701, 4702, | 23:52 |
| povbot | /svn/commits: Ignored: 4613, 4625, 4626, 4629, 4630, 4631, 4638, 4651, 4673, 4681, 4692, | 23:52 |
| povbot | /svn/commits: * srichter committed revision 4858: | 23:55 |
| povbot | /svn/commits: Remove to replace with new version | 23:55 |
| *** alga has quit IRC | 23:56 | |
| *** mgedmin has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!