IRC log of #schooltool for Thursday, 2004-10-14

**** BEGIN LOGGING AT Thu Oct 14 12:46:44 2004
-->You are now talking on #schooltool12:46
---#schooltool :[freenode-info] why register and identify? your IRC nick is how people know you.
---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 #schooltool17:35
<--hazmat has quit ("Leaving")18:06
-->gintas ( has joined #schooltool18:18
-->pips (~philipp@ has joined #schooltool18:37
pipsmgedmin: r u there?18:50
pipsoh alright18:50
pipsdid u get my mail?18:51
pipswhat do you think about our requirements, then?18:53
mgedminthey're not entirely straightforward18:54
mgedminbut I think implementable18:54
mgedminsynchronizing free/busy data between two schools is interesting18:54
pipswhere do you think are the tricky spots?18:55
mgedminit can probably be done by having two schooltool instances18:55
mgedminand custom event handlers to update free/busy data on the other instance18:55
pipsa ha18:55
pipsi have been talking to th1a about it18:56
pipsoh you are here too!18:56
th1aI was making lunch.18:57
pipsmgedmin: tom and i were discussing whether it would be better to have two instances or two schools in one instance..18:57
th1aI 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
pipsthe 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
pipsoh i see18:59
pipsso for a demo we do it in one instance, but really we want to do it with two! 19:00
pipstom, do you really think it would be easier to try to cover both schools in one instance for the demo?!19:01
pipsit's sort of our "main selling point", that we can show that they can coordinate their shared rooms..19:02
th1aI guess it depends on how much work it will take to allow multiple instances to coordinate.19:03
pipsmgedmin: what do you reckon?19:04
mgedminI think it is simpler to syncrhonize two instances19:04
th1aI suppose the XP approach to the problem is that we should just get what you need working in the quickest way possible.19:04
th1aI'm tending to think of it as a big architectural decision.19:04
mgedminI might be wrong, though19:04
mgedminthe simplest solution the way I see it is to have two schooltool instances -- for P and T19:05
mgedmin(I hope I remembered the letters right)19:05
pipsyep P and T is fine19:05
mgedminthen have a "person" representing the other school in each of the instances19:05
mgedminand book resources for that person19:05
mgedminas to how to do that automatically...19:06
th1aSo you've got two instances which need to stay in sync.19:06
mgedminone possibility is to write an event handler19:06
mgedminthat notices when resource calendars/timetables are modified19:06
mgedminand uses RESTive calls to make the same modifications on the other instance19:06
mgedmin(but rather than using the real person use the school representative person)19:06
th1aI'm a bit worried that neither would be authoritative.19:07
mgedminyou will also need to modify timetable/calendar modification event to publish these events, because iirc we do not do that now19:07
pipsi was thinking the same thing, what about rights management...19:07
mgedminauthoritativity might be a problem19:07
mgedminan alternative is to have both instances in the same ZODB instance19:07
mgedmindifferent root objects19:07
SteveAuse RDF and make the secondary server poll ?19:08
mgedminand then directly modify the data of the other instance19:08
mgedminyou will need to write code in either case19:08
pipsSteveA: oops that went over my head! 19:08
SteveAI'm popping in without really knowing the context19:09
SteveAfeel free to ignore19:09
th1aI was thinking that we could create proxy objects that would represent objects in an external SchoolTool instance.19:09
pipsth1a: how does that solve the authoritativity prob?19:10
th1aWell, say school S has the authoritative calendar.19:10
mgedminth1a: good idea -- you could set a password for the person T/P19:10
mgedminand give him manager access19:10
mgedminno real person would know that passwords19:10
mgedminonly the other system19:10
th1aWhen 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
th1aThe school P event is like a shortcut to the event in the school S repository.19:12
pipsoh i see you suggest one "authorative" repository19:12
th1aIf you don't do it that way, you get a lot of complexity when things inevitably get out of sync.19:13
pipsi guess that works if one school is considered to be authorative over the resources19:13
th1aIt wouldn't be apparent to users.19:13
pipsour 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
th1aThey wouldn't even have to know what's going on internally :-)19:14
th1aWe could also have the authoritative calendar in a third instance, but I don't see any reason to do that.19:15
pipsin 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
th1aAny compelling reason at least.19:16
pipswell i think on the long run we definitely need separate instances for each school19:17
th1aYeah.  As you can see, there are inevitably some tricky issues involved.19:17
th1aBut we definitely plan on tackling them.19:18
pipsin our *special case* with shared resources, the idea with declaring one repository authoritive doesn't seem such a bad idea..19:18
pipsi mean i sponteanously like the proxy idea.. although i'm not sure what the architectural "repercussions" might be19:19
th1aIt depends on how deep you take it.19:20
pipsSteveA: r u still there?19:20
pipsi have refined our requirements draft further today.19:21
pipsi got some more answers to questions from our timetable manager19:21
pipsso how do we take it from here?19:22
pips(everybody passed out)19:23
th1aWell, 19:23
th1aI think coordinating two instances is a couple weeks serious work.19:24
th1aWhich wouldn't happen for a month/six weeks at least.19:24
th1aAnd will be tricky.19:25
th1aOn the other hand, I still think you can go ahead and get started with both schools in one instance.19:25
pipswhat 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
pipsgregoire will be back from the zope3 sprint tomorrow19:27
th1aI think we can do a decent demo with one instance.19:27
th1aCoordinating multiple instances is too much deep voodoo for me to write.19:28
pipsit also depends how tough it will be for him to get into schooltool, so we can get a decent demo...19:28
pipsth1a: you said that we should maybe do a "throw-away" kind of demo, did I understand you right there?19:30
pipsok, i guess we discuss this best with greg19:31
pipsi'll discuss it with him and then we can talk about it on irc... what do you think?19:32
*pips searching for the log of x-chat19:33
th1aOh shoot.  I think I forgot to send you the log of the chat we had a couple days ago.19:34
th1aSorry about that.19:34
pipsno problem. but i had been wondering about that.19:34
pipsugh, "raw log" isn't what i want, i think19:36
pipsah good old friend copy-paste19:39
pipsok, i hope to see you all soon on irc19:41
th1aI'll be around.19:41
pipstomorrow same time-ish19:41
pipsbye !!19:41
<--pips has quit ("Leaving")19:42
<--gintas has quit (Read error: 60 (Operation timed out))20:16
-->gintas ( has joined #schooltool21:40
---SteveA is now known as SteveA|way22:40
**** ENDING LOGGING AT Thu Oct 14 23:07:46 2004

Generated by 2.15.1 by Marius Gedminas - find it at!