| **** BEGIN LOGGING AT Thu Oct 14 12:46:44 2004 | ||
| -->You are now talking on #schooltool | 12:46 | |
| ---#schooltool :[freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup | 12:46 | |
| ---Disconnected (). | 14:50 | |
| **** ENDING LOGGING AT Thu Oct 14 14:50:16 2004 | ||
| **** BEGIN LOGGING AT Thu Oct 14 17:35:21 2004 | ||
| -->You are now talking on #schooltool | 17:35 | |
| <--hazmat has quit ("Leaving") | 18:06 | |
| -->gintas (~gintas@office.pov.lt) has joined #schooltool | 18:18 | |
| -->pips (~philipp@195.216.81.229) has joined #schooltool | 18:37 | |
| pips | hi | 18:37 |
|---|---|---|
| pips | mgedmin: r u there? | 18:50 |
| mgedmin | yes | 18:50 |
| pips | oh alright | 18:50 |
| pips | did u get my mail? | 18:51 |
| pips | ? | 18:51 |
| pips | huh? | 18:52 |
| mgedmin | yes | 18:52 |
| pips | good | 18:52 |
| pips | what do you think about our requirements, then? | 18:53 |
| mgedmin | they're not entirely straightforward | 18:54 |
| mgedmin | but I think implementable | 18:54 |
| mgedmin | synchronizing free/busy data between two schools is interesting | 18:54 |
| pips | where do you think are the tricky spots? | 18:55 |
| mgedmin | it can probably be done by having two schooltool instances | 18:55 |
| pips | interesting | 18:55 |
| mgedmin | and custom event handlers to update free/busy data on the other instance | 18:55 |
| pips | a ha | 18:55 |
| pips | i have been talking to th1a about it | 18:56 |
| th1a | Hi | 18:56 |
| pips | oh you are here too! | 18:56 |
| pips | hi | 18:56 |
| th1a | I was making lunch. | 18:57 |
| pips | mgedmin: tom and i were discussing whether it would be better to have two instances or two schools in one instance.. | 18:57 |
| th1a | I don't have much doubt that one instance per school would be better, but in the short run we should be able to do it as one. | 18:58 |
| pips | the overlap of the schools is really only about the shared ressources (rooms). otherwise (teachers, students, etc.) the schools are quite separate. | 18:58 |
| pips | (btw i am running on ubuntu since 30 mins :-) | 18:59 |
| pips | oh i see | 18:59 |
| pips | so for a demo we do it in one instance, but really we want to do it with two! | 19:00 |
| pips | hmm | 19:01 |
| pips | tom, do you really think it would be easier to try to cover both schools in one instance for the demo?! | 19:01 |
| pips | it's sort of our "main selling point", that we can show that they can coordinate their shared rooms.. | 19:02 |
| th1a | I guess it depends on how much work it will take to allow multiple instances to coordinate. | 19:03 |
| pips | mgedmin: what do you reckon? | 19:04 |
| mgedmin | I think it is simpler to syncrhonize two instances | 19:04 |
| th1a | I suppose the XP approach to the problem is that we should just get what you need working in the quickest way possible. | 19:04 |
| pips | right! | 19:04 |
| th1a | I'm tending to think of it as a big architectural decision. | 19:04 |
| mgedmin | I might be wrong, though | 19:04 |
| mgedmin | the simplest solution the way I see it is to have two schooltool instances -- for P and T | 19:05 |
| mgedmin | (I hope I remembered the letters right) | 19:05 |
| pips | yep P and T is fine | 19:05 |
| mgedmin | then have a "person" representing the other school in each of the instances | 19:05 |
| mgedmin | and book resources for that person | 19:05 |
| pips | oh | 19:05 |
| mgedmin | as to how to do that automatically... | 19:06 |
| th1a | So you've got two instances which need to stay in sync. | 19:06 |
| mgedmin | one possibility is to write an event handler | 19:06 |
| mgedmin | that notices when resource calendars/timetables are modified | 19:06 |
| mgedmin | and uses RESTive calls to make the same modifications on the other instance | 19:06 |
| mgedmin | (but rather than using the real person use the school representative person) | 19:06 |
| th1a | I'm a bit worried that neither would be authoritative. | 19:07 |
| mgedmin | you will also need to modify timetable/calendar modification event to publish these events, because iirc we do not do that now | 19:07 |
| pips | i was thinking the same thing, what about rights management... | 19:07 |
| mgedmin | authoritativity might be a problem | 19:07 |
| mgedmin | an alternative is to have both instances in the same ZODB instance | 19:07 |
| mgedmin | different root objects | 19:07 |
| SteveA | use RDF and make the secondary server poll ? | 19:08 |
| mgedmin | and then directly modify the data of the other instance | 19:08 |
| mgedmin | you will need to write code in either case | 19:08 |
| pips | SteveA: oops that went over my head! | 19:08 |
| SteveA | I'm popping in without really knowing the context | 19:09 |
| SteveA | feel free to ignore | 19:09 |
| th1a | I was thinking that we could create proxy objects that would represent objects in an external SchoolTool instance. | 19:09 |
| pips | th1a: how does that solve the authoritativity prob? | 19:10 |
| th1a | Well, say school S has the authoritative calendar. | 19:10 |
| mgedmin | th1a: good idea -- you could set a password for the person T/P | 19:10 |
| mgedmin | and give him manager access | 19:10 |
| mgedmin | no real person would know that passwords | 19:10 |
| mgedmin | only the other system | 19:10 |
| th1a | When you create an event at school P, it looks like it is happening in the local repository, but really it is adding the event in the school S repository. | 19:11 |
| th1a | The school P event is like a shortcut to the event in the school S repository. | 19:12 |
| pips | oh i see you suggest one "authorative" repository | 19:12 |
| th1a | Right. | 19:12 |
| pips | interesting | 19:12 |
| th1a | If you don't do it that way, you get a lot of complexity when things inevitably get out of sync. | 19:13 |
| pips | i guess that works if one school is considered to be authorative over the resources | 19:13 |
| th1a | It wouldn't be apparent to users. | 19:13 |
| pips | our schools P and T get along fine, but i wonder... | 19:14 |
| pips | ... what happens if they increasingly book out rooms to external schools? | 19:14 |
| th1a | They wouldn't even have to know what's going on internally :-) | 19:14 |
| th1a | We could also have the authoritative calendar in a third instance, but I don't see any reason to do that. | 19:15 |
| pips | in my last remark i was wondering about tracking bookings and then having to send some data over to the accounting systems of each school etc. | 19:15 |
| th1a | Any compelling reason at least. | 19:16 |
| pips | ? | 19:16 |
| pips | ah | 19:16 |
| pips | well i think on the long run we definitely need separate instances for each school | 19:17 |
| th1a | Yeah. As you can see, there are inevitably some tricky issues involved. | 19:17 |
| th1a | But we definitely plan on tackling them. | 19:18 |
| pips | in our *special case* with shared resources, the idea with declaring one repository authoritive doesn't seem such a bad idea.. | 19:18 |
| pips | i mean i sponteanously like the proxy idea.. although i'm not sure what the architectural "repercussions" might be | 19:19 |
| th1a | It depends on how deep you take it. | 19:20 |
| pips | SteveA: r u still there? | 19:20 |
| pips | i have refined our requirements draft further today. | 19:21 |
| pips | i got some more answers to questions from our timetable manager | 19:21 |
| pips | :-) | 19:21 |
| pips | hmm | 19:22 |
| pips | so how do we take it from here? | 19:22 |
| pips | (everybody passed out) | 19:23 |
| th1a | Well, | 19:23 |
| th1a | I think coordinating two instances is a couple weeks serious work. | 19:24 |
| pips | right | 19:24 |
| th1a | Which wouldn't happen for a month/six weeks at least. | 19:24 |
| pips | hm | 19:25 |
| th1a | And will be tricky. | 19:25 |
| th1a | On the other hand, I still think you can go ahead and get started with both schools in one instance. | 19:25 |
| pips | what is your time schedule? I mean, for us, if we don't get a decent demo to convince management, our schools might just pull the plug on my pet project... | 19:26 |
| pips | :-( | 19:26 |
| pips | gregoire will be back from the zope3 sprint tomorrow | 19:27 |
| th1a | I think we can do a decent demo with one instance. | 19:27 |
| th1a | Coordinating multiple instances is too much deep voodoo for me to write. | 19:28 |
| pips | it also depends how tough it will be for him to get into schooltool, so we can get a decent demo... | 19:28 |
| pips | th1a: you said that we should maybe do a "throw-away" kind of demo, did I understand you right there? | 19:30 |
| th1a | Yeah. | 19:30 |
| pips | right | 19:30 |
| pips | ok, i guess we discuss this best with greg | 19:31 |
| pips | i'll discuss it with him and then we can talk about it on irc... what do you think? | 19:32 |
| th1a | Sure. | 19:32 |
| pips | ok | 19:32 |
| *pips searching for the log of x-chat | 19:33 | |
| th1a | Oh shoot. I think I forgot to send you the log of the chat we had a couple days ago. | 19:34 |
| th1a | Sorry about that. | 19:34 |
| pips | no problem. but i had been wondering about that. | 19:34 |
| pips | ugh, "raw log" isn't what i want, i think | 19:36 |
| pips | ah good old friend copy-paste | 19:39 |
| pips | ok, i hope to see you all soon on irc | 19:41 |
| th1a | I'll be around. | 19:41 |
| pips | tomorrow same time-ish | 19:41 |
| th1a | Yeah. | 19:41 |
| pips | bye !! | 19:41 |
| <--pips has quit ("Leaving") | 19:42 | |
| <--gintas has quit (Read error: 60 (Operation timed out)) | 20:16 | |
| -->gintas (~gintas@adsl-212-59-30-232.takas.lt) has joined #schooltool | 21:40 | |
| ---SteveA is now known as SteveA|way | 22:40 | |
| **** ENDING LOGGING AT Thu Oct 14 23:07:46 2004 | ||
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!