| **** BEGIN LOGGING AT Wed Sep 15 11:31:25 2004 | ||
| -->You are now talking on #schooltool | 11:31 | |
| -TomLogging-This channel is logged - http://stone.tuttlesvc.org:880/logbot/ | 11:31 | |
| -->thisfred (~thisfred@a213-84-57-72.adsl.xs4all.nl) has joined #schooltool | 12:04 | |
| **** ENDING LOGGING AT Wed Sep 15 12:44:17 2004 | ||
| **** BEGIN LOGGING AT Wed Sep 15 14:04:52 2004 | ||
| -->You are now talking on #schooltool | 14:04 | |
| -TomLogging-This channel is logged - http://stone.tuttlesvc.org:880/logbot/ | 14:04 | |
| <--Aiste has quit (saberhagen.freenode.net irc.freenode.net) | 14:37 | |
| -->Aiste (~aiste@office.pov.lt) has joined #schooltool | 14:38 | |
| <--tvon has quit (saberhagen.freenode.net irc.freenode.net) | 14:40 | |
| -->tvon (tvon@dsl093-119-225.blt1.dsl.speakeasy.net) has joined #schooltool | 14:40 | |
| <--gintas has quit (Read error: 60 (Operation timed out)) | 15:04 | |
| -->gintas (~gintautas@office.pov.lt) has joined #schooltool | 15:30 | |
| ---Disconnected (). | 16:48 | |
| **** ENDING LOGGING AT Wed Sep 15 16:48:26 2004 | ||
| **** BEGIN LOGGING AT Wed Sep 15 20:09:57 2004 | ||
| -->You are now talking on #schooltool | 20:09 | |
| -TomLogging-This channel is logged - http://stone.tuttlesvc.org:880/logbot/ | 20:09 | |
| bskahan | Hi everyone | 20:16 |
|---|---|---|
| bskahan | tvon is running a little late, but he'll be here soon | 20:16 |
| -->th1a (~hoffman@128.148.208.101) has joined #schooltool | 20:17 | |
| th1a | OK, I'm here. | 20:18 |
| th1a | Shall we begin? Don't want to keep the Lithuanians up too late. | 20:19 |
| bskahan | yeah | 20:19 |
| th1a | Let's try to start with the functionality we need to create next, rather than jumping into architectural questions. | 20:19 |
| bskahan | let me see if I have a good idea, | 20:20 |
| bskahan | right now students are represented by name and DOB | 20:20 |
| bskahan | in real world situations schools are going to be requires to track a set of information, and then probably want to add additional information that isn't required | 20:21 |
| bskahan | the required info will probably be consistent by region | 20:21 |
| bskahan | so multiple schools may be able to use that required set | 20:21 |
| bskahan | the type of information ranges from race/ethnicity, gender to family relationships and class relationships | 20:22 |
| bskahan | the data will primarily be used for searching, sorting and reporting | 20:23 |
| th1a | Yep. | 20:23 |
| bskahan | e.g., give me grade reports for all african american mails in their first year | 20:24 |
| bskahan | s/mails/males | 20:24 |
| th1a | by class relationships do you mean economic class? | 20:24 |
| bskahan | no, school class | 20:24 |
| th1a | That's not "student information," in this case. | 20:25 |
| bskahan | hasTaken, isEnrolledIn, requiredToTake | 20:25 |
| bskahan | ok | 20:25 |
| th1a | That'll be handled by other systems. | 20:25 |
| th1a | Dynamic stuff like that is different. | 20:25 |
| bskahan | ok, needs to be accounted for so they can interelate | 20:25 |
| bskahan | but makes sense to be seperate | 20:26 |
| th1a | This "student information" is sort of a bag for static data not handled by other specific systems. | 20:26 |
| bskahan | ok | 20:27 |
| -->tvon (~tvon@h-67-100-157-190.mclnva23.covad.net) has joined #schooltool | 20:27 | |
| th1a | Stuff that will be directly entered and only changed manually. | 20:27 |
| tvon | Hello everyone | 20:27 |
| th1a | At least that's the way I see it. | 20:27 |
| th1a | Hi Tom. | 20:27 |
| bskahan | that makes sense, other systems can refernce it as "more information" | 20:28 |
| th1a | Up to this point, I've been proposing an ambitious and abstracted approach -- | 20:29 |
| th1a | creating a system that will allow the school to set up custom fields for student data through the web. | 20:30 |
| th1a | And I'd like to have that in the long run, | 20:30 |
| th1a | but it is by no means necessary to have things ready for HTH in April. | 20:30 |
| *bskahan nods | 20:30 | |
| th1a | It would be adequate to just do an add-on information component for HTH. | 20:31 |
| th1a | And perhaps prudent. | 20:31 |
| tvon | Yeah, a TTW system can be fairly complicated and time consuming | 20:31 |
| th1a | But in the long run I'd prefer if one didn't have to write Python to do this customization at a school. | 20:32 |
| tvon | definately | 20:32 |
| th1a | Based on the emails this morning, it is a little more complicated that I gathered to do it all ttw. | 20:32 |
| mgedmin | I don't think it's all that complicated | 20:32 |
| mgedmin | except that you won't get it for free just by using zope schemas and forms | 20:33 |
| th1a | OK. | 20:33 |
| th1a | How would it work in SchoolTool, then? | 20:33 |
| *mgedmin thinks | 20:34 | |
| mgedmin | you'd probably want to define a named schema | 20:34 |
| mgedmin | e.g "student info" | 20:34 |
| mgedmin | I think you should be able to update the schema via the RESTive interface (some sort of XML description about field names and types) | 20:34 |
| mgedmin | and also a TTW editing form | 20:34 |
| th1a | Do you mean a RelaxNG schema in this case? | 20:35 |
| mgedmin | not necessarily | 20:35 |
| mgedmin | full relaxng might be too much to implement | 20:35 |
| mgedmin | we could define a custom xml format or use a subset of some existing standard | 20:36 |
| mgedmin | or even a full standard | 20:36 |
| *mgedmin wishes he knew more about XForm | 20:36 | |
| mgedmin | once you have named schemas | 20:36 |
| mgedmin | you should be able to attach facets to persons | 20:36 |
| mgedmin | we'd have a new type of facet -- CustomDataFacet or whatever | 20:36 |
| mgedmin | that knows the name of the schema | 20:36 |
| mgedmin | and holds values for all fields defined in the schema | 20:37 |
| mgedmin | or maybe we want a different kind of facet for every schema | 20:37 |
| mgedmin | anyway, once you put a facet on a person, you have a place to store additional info | 20:37 |
| mgedmin | I'd like to mention that currently all person info (name, date of birth, photo) is stored in a facet | 20:37 |
| mgedmin | the web interface hides these implementation details and simply shows the info as something that a person object has | 20:38 |
| th1a | In one facet with multiple attributes? | 20:38 |
| mgedmin | yes | 20:38 |
| th1a | OK, I was trying to figure that out last night. | 20:38 |
| mgedmin | next, we'd need a web interface view that could construct forms according to a schema | 20:39 |
| mgedmin | and hook it up to the web interface | 20:39 |
| mgedmin | one question: once a schema is defined, can it be changed? | 20:40 |
| mgedmin | if so, we'd need to deal with schema versions | 20:40 |
| th1a | Well, it would be nice... but versioning is always a bitch. | 20:40 |
| mgedmin | (go through all object that have a data facet with an older version of a schema, and add/remove fields as necessary) | 20:40 |
| tvon | You mean if server A has a schema at version 'foo' and server B has the same schema at version 'bar' ? | 20:40 |
| mgedmin | no, I mean that I create a schema | 20:41 |
| mgedmin | fill in the info for a couple of students | 20:41 |
| mgedmin | then decide that I need a new field in the schema | 20:41 |
| mgedmin | (everything on the same server) | 20:41 |
| bskahan | do we think that schools will be changing the schema more than once per year (at most) | 20:42 |
| th1a | They shouldn't be. | 20:42 |
| th1a | They would change infrequently. | 20:42 |
| mgedmin | a simpler solution is to disallow schema changes | 20:43 |
| bskahan | yeah, so there may be a need to upgrade students | 20:43 |
| mgedmin | you go to the schema definition view | 20:43 |
| mgedmin | define a schema | 20:43 |
| mgedmin | edit it | 20:43 |
| th1a | Of course. | 20:43 |
| mgedmin | the you click 'create' | 20:43 |
| mgedmin | and only then you're able to create facets for this schema | 20:43 |
| mgedmin | next year you can create a new schema ("student info 2005") | 20:43 |
| mgedmin | if you do not need to update the data for old students | 20:43 |
| mgedmin | however if you do need to update existing data, it would be very inconvenient | 20:44 |
| th1a | Couldn't you just import the data into the new schema facet? | 20:44 |
| bskahan | unfortunately, the laws for what must be tracked will change, and the existing students wouldn't have that | 20:44 |
| mgedmin | you couldn't just import because the schema is different | 20:45 |
| bskahan | so there would have to be a migration path from "student-info-2005" to "student-info-2007" | 20:45 |
| mgedmin | you could copy the data manually, but that would be tedious | 20:45 |
| mgedmin | if we're talking about migration paths, then it would be simpler to allow versioning of schemas | 20:45 |
| th1a | It is safe to assume that we won't have massive changes in schemas. | 20:45 |
| tvon | you could come up with some sort of field mapping setup | 20:45 |
| mgedmin | we could store high-level differences between versions (e.g. v2 -> v3: field 'dob' was renamed to 'date_of_birth', v3 -> v4: field 'comment' added, default value "") | 20:46 |
| tvon | which we might want anyways for migration from other systems | 20:46 |
| th1a | Schools will get a couple new requirements, drop a few obselete ones. | 20:46 |
| bskahan | there won't be massive changes, and the probably won't come every year, more like every 5 years | 20:46 |
| gintas | perhaps a simple solution would be enough; newly created fields on a schema are set to None on all facets that conform to the schema | 20:47 |
| gintas | when a schema field is deleted, so is all data in all facets that conform to the schema | 20:47 |
| gintas | and we could deal with renames too | 20:47 |
| th1a | That sounds adequate to me. | 20:47 |
| mgedmin | I don't know if I want to mention the possibility of extracting old data via REST, using XSLT or some other transformation, and then uploading the transformed data again via REST; all in an external script | 20:47 |
| mgedmin | it's probably not something that schools would want to do | 20:47 |
| th1a | No... | 20:47 |
| gintas | assuming that we want to make things easier... | 20:48 |
| gintas | actually the schema update process might be quite simple if we make it work one-step-at-a-time | 20:48 |
| th1a | Well, regardless, it sounds like we have a path forward on the overall solution. | 20:49 |
| gintas | i.e., you choose to create a field, press 'Submit', and all facets are updated immediately; similarly for rename and delete | 20:49 |
| th1a | tvon and bskahan: do you have a sense of what direction you're looking now? | 20:50 |
| tvon | th1a: yes | 20:50 |
| bskahan | a much better one, I'm going to look over the existing student Facet system | 20:51 |
| th1a | OK. So you guys should dig around there. | 20:51 |
| mgedmin | it is somewhat similair to Zope 3 annotations (especially Dublin Core), if you're familiar with that | 20:51 |
| *bskahan nods | 20:51 | |
| mgedmin | we do not use adapters (yet -- initially had a requirement to reduce dependencies on parts of zope 3 to as little as possible) | 20:52 |
| mgedmin | but the syntax is similair | 20:52 |
| mgedmin | if you have an application object (or anything that is IFaceted), you can say | 20:53 |
| mgedmin | fm = FacetManager(obj) | 20:53 |
| mgedmin | and then you can iterate over all facets or get one by name | 20:53 |
| mgedmin | (see IFacetManager) | 20:53 |
| bskahan | I'll take a look at that tomorrow, looked at it last weekend, but hopefully a better context now | 20:54 |
| mgedmin | there is also some facility to say that adding an object to this group automatically adds a new facet of a certain type on the object | 20:54 |
| mgedmin | some facets have a fixed name (and only one copy of the facet can be added to an object) | 20:54 |
| mgedmin | other facets get automatically selected names (and you can have many copies of a facet of the same type) | 20:55 |
| gintas | bskahan: feel free to ask us (well, at least me) for help on IRC, that will save you some trouble | 20:55 |
| bskahan | gintas: thanks! | 20:55 |
| th1a | Can we move on to a couple other questions? | 20:56 |
| bskahan | yeah, we should | 20:56 |
| bskahan | I have to run not too long | 20:56 |
| th1a | We're going to be adding functionality to SchoolTool for the next six months -- is there anything POV would like to change in the core before we get into that? | 20:57 |
| th1a | Things that would cause API breakage? | 20:57 |
| tvon | Folks, I have to get going myself. | 20:58 |
| th1a | OK. | 20:58 |
| th1a | I think we got through the most important bit for you. | 20:59 |
| tvon | I'm on IRC 99% of the time, so ping me if anyone wants to chat, other wise I'll be pinging all of you at various points to ask questions :) | 20:59 |
| tvon | I'll check the logs to see what discussion I might have missed in here | 20:59 |
| *tvon tips his hat | 20:59 | |
| mgedmin | I'm not sure about core changes | 20:59 |
| th1a | Bye. | 20:59 |
| tvon | Nice talking to you all | 20:59 |
| <--tvon (~tvon@h-67-100-157-190.mclnva23.covad.net) has left #schooltool ("Leaving") | 20:59 | |
| mgedmin | SteveA wanted us to move towards Zope 3 | 20:59 |
| mgedmin | (publisher, views, etc.) | 21:00 |
| th1a | Was the previous requirement to stay away from Zope 3 based on the fact that it was still changing quickly? | 21:00 |
| mgedmin | that's my understanding of it | 21:00 |
| th1a | Was the decision to use Twisted made for the same reason? | 21:01 |
| mgedmin | probably -- we did not want to implement an HTTP server from scratch | 21:01 |
| th1a | But it wasn't because of deficiencies in Zope 3's server. | 21:02 |
| mgedmin | you should ask Steve or Mark about that | 21:02 |
| gintas | I don't think that the requirement was based on technical reasons | 21:02 |
| th1a | OK. Brian sent Steve an email about that this afternoon, actually. | 21:02 |
| mgedmin | I think there also was the risk that we would spend time working on Zope 3 instead of developing schooltool | 21:02 |
| bskahan | I CC'd everyone | 21:02 |
| th1a | Yeah. | 21:03 |
| th1a | I think Mark doesn't want us to get sucked in to other related projects. | 21:03 |
| mgedmin | back to core changes | 21:03 |
| mgedmin | there was a plan to make URIs objects instead of interfaces | 21:04 |
| mgedmin | (URIs in this context are identifiers for things like relationship types and roles) | 21:04 |
| mgedmin | (see uris.py and ISpecificURI in interfaces.py) | 21:04 |
| bskahan | looking at them now | 21:05 |
| mgedmin | I do not recall other core changes | 21:05 |
| mgedmin | but in general SchoolTool was developed in an XP way | 21:05 |
| mgedmin | (do what is needed now, do not try to predict the future, you'll refactor when that becomes necessary) | 21:06 |
| mgedmin | so the APIs aren't designed to be stable | 21:06 |
| th1a | OK. | 21:07 |
| mgedmin | I think that's one of the reasons why Steve wants us to move towards Zope 3 component architecture | 21:08 |
| mgedmin | easier pluggability | 21:08 |
| bskahan | mgedmin: what's the reason for moving to objects for URIs? | 21:09 |
| mgedmin | interfaces are clumsy | 21:09 |
| mgedmin | e.g. when you have a relationship | 21:09 |
| *bskahan nods | 21:09 | |
| mgedmin | and you want to get the name of it | 21:09 |
| th1a | Yeah, even I noticed that. | 21:10 |
| mgedmin | you have to use nameURI(relationship_type) | 21:10 |
| mgedmin | instead of relationship_type.name | 21:10 |
| mgedmin | we initially thought what we might want to use URIs as marker interfaces | 21:10 |
| mgedmin | but we never needed that | 21:10 |
| th1a | Changing the URI's to objects wouldn't be too hard, just a bunch of little code changes, right? | 21:11 |
| th1a | Syntax changes. | 21:11 |
| th1a | Everything is just a bunch of little cod changes :-) | 21:12 |
| th1a | code | 21:12 |
| th1a | But fairly superficial changes? | 21:12 |
| mgedmin | yes | 21:13 |
| th1a | I'd be in favor of getting that out of the way. | 21:14 |
| th1a | Otherwise, I guess we should just go forward. | 21:15 |
| th1a | Perhaps we can do the URI switcheroo at the beginning of the next POV SchoolBell iteration. | 21:15 |
| th1a | Then in November I'd like to see an example product and documentation on how to create add-on products for SchoolTool. | 21:16 |
| mgedmin | sure | 21:16 |
| th1a | And then just putting together functionality for the HTH release (which will be 1.0 beta) in April. | 21:18 |
| bskahan | We're going to do the student data as an add-on product | 21:18 |
| th1a | I don't think so. | 21:18 |
| th1a | I mean, I don't think we need to. | 21:19 |
| th1a | Or, keeping it in the core would be consistent with the way we've been doing things so far. | 21:20 |
| bskahan | ok | 21:20 |
| th1a | If it isn't in the core, than probably several other things should be moved out of the core. | 21:20 |
| th1a | But there isn't a compelling case to do that now, I don't think. | 21:20 |
| bskahan | allright | 21:21 |
| th1a | Since it is a generic, customizable system itself. | 21:21 |
| th1a | Are we following Zope 3 coding conventions? | 21:22 |
| th1a | Style? | 21:22 |
| gintas | style is fairly consistent in the Python world I think | 21:22 |
| bskahan | 4 spaces? | 21:22 |
| mgedmin | of course ;) | 21:22 |
| bskahan | ;) | 21:22 |
| th1a | But you guys haven't specifically been following anything in particular? | 21:22 |
| mgedmin | PEP-8 basically | 21:22 |
| mgedmin | also Zope 3 influence | 21:23 |
| gintas | well, there's quite enough code for you to look at | 21:23 |
| th1a | It would be nice to be able to point to something specific on the web site. | 21:24 |
| bskahan | python guidelines on python.org | 21:24 |
| mgedmin | http://www.python.org/peps/pep-0008.html | 21:24 |
| th1a | Sounds good, anything else? | 21:24 |
| bskahan | http://www.python.org/peps/pep-0008.txt | 21:25 |
| bskahan | heh | 21:25 |
| th1a | I mean, anything else for this meeting... | 21:25 |
| bskahan | not from our side | 21:25 |
| th1a | It is getting late in Lithuania. | 21:25 |
| mgedmin | yes | 21:25 |
| th1a | Is alga on his honeymoon? | 21:25 |
| mgedmin | yes | 21:25 |
| mgedmin | by the seaside | 21:25 |
| bskahan | mgedmin, gintas: what time is it? | 21:25 |
| mgedmin | 21:15 | 21:25 |
| th1a | How was the wedding? | 21:25 |
| gintas | 21:25 | 21:26 |
| gintas | :) | 21:26 |
| mgedmin | the wedding celebration was postponed | 21:26 |
| mgedmin | Albert's grandmother died | 21:26 |
| th1a | That's too bad. | 21:26 |
| th1a | Well, let's adjourn. | 21:27 |
| mgedmin | ok | 21:27 |
| th1a | Thanks, guys. | 21:27 |
| bskahan | have a good night folks | 21:27 |
| mgedmin | see you on irc | 21:27 |
| bskahan | ;) | 21:27 |
| th1a | Bye. | 21:27 |
| mgedmin | bye | 21:27 |
| <--th1a has quit () | 21:27 | |
| ---Disconnected (). | 21:28 | |
| **** ENDING LOGGING AT Wed Sep 15 21:28:18 2004 | ||
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!