| *** Aiste has joined #schooltool | 00:01 | |
| *** SteveA has quit IRC | 00:23 | |
| *** SteveA has joined #schooltool | 00:26 | |
| *** Aiste has quit IRC | 01:07 | |
| *** SteveA has quit IRC | 01:12 | |
| *** SteveA has joined #schooltool | 01:24 | |
| *** jinty has quit IRC | 01:28 | |
| *** phlak has joined #schooltool | 01:47 | |
| *** phlak has left #schooltool | 01:47 | |
| *** hazmat_ has joined #schooltool | 02:08 | |
| *** hazmat has quit IRC | 02:24 | |
| *** d2m has quit IRC | 02:27 | |
| *** SteveA has quit IRC | 02:52 | |
| *** SteveA has joined #schooltool | 02:55 | |
| *** hazmat_ has quit IRC | 03:08 | |
| *** SteveA has quit IRC | 03:49 | |
| *** SteveA has joined #schooltool | 03:51 | |
| *** Deafcon has joined #schooltool | 04:28 | |
| *** Deafcon has left #schooltool | 04:47 | |
| *** SteveA has quit IRC | 05:18 | |
| *** SteveA has joined #schooltool | 05:21 | |
| *** SteveA has quit IRC | 06:13 | |
| *** SteveA has joined #schooltool | 06:21 | |
| *** bska|mobile has quit IRC | 06:45 | |
| *** SteveA has quit IRC | 07:41 | |
| *** SteveA has joined #schooltool | 07:44 | |
| *** Aiste has joined #schooltool | 08:44 | |
| *** SteveA_ has joined #schooltool | 08:49 | |
| *** SteveA has quit IRC | 08:54 | |
| *** SteveA_ is now known as SteveA | 08:54 | |
| *** Aiste has quit IRC | 09:02 | |
| *** d2m has joined #schooltool | 09:56 | |
| *** SteveA has quit IRC | 10:13 | |
| *** SteveA has joined #schooltool | 10:14 | |
| *** SteveA has quit IRC | 11:21 | |
| *** SteveA has joined #schooltool | 11:24 | |
| *** mgedmin has joined #schooltool | 11:55 | |
| *** mgedmin has quit IRC | 11:57 | |
| *** Aiste has joined #schooltool | 12:20 | |
| *** SteveA has quit IRC | 12:22 | |
| *** SteveA has joined #schooltool | 12:39 | |
| *** mgedmin has joined #schooltool | 12:59 | |
| *** SteveA has quit IRC | 14:05 | |
| *** SteveA has joined #schooltool | 14:16 | |
| mgedmin | <srichter> btw, I just E-mailed Stuart about pytz inclusion | 14:42 |
|---|---|---|
| mgedmin | we can hope that zope 3.1 will come with pytz | 14:43 |
| mgedmin | that would simplify our dependencies | 14:43 |
| *** Awayblia is now known as Workblia | 14:56 | |
| SteveA | mgedmin: this helps out launchpad too, so I'm sure it will be okay. | 15:02 |
| SteveA | mgedmin: can you allow me to post to schooltool-dev as steve@canonial.com ? | 15:02 |
| mgedmin | I guess so | 15:02 |
| mgedmin | you can also subscribe with that address and disable delivery | 15:02 |
| SteveA | gawd, i'm so lazy | 15:03 |
| mgedmin | mailman's password is the same as for old lists, btw, so you have full access | 15:03 |
| mgedmin | gaah, my mozilla forgot the password | 15:03 |
| mgedmin | gaah, I forgot the password too | 15:04 |
| mgedmin | ok, I'm in | 15:05 |
| mgedmin | where is that setting? | 15:05 |
| mgedmin | SteveA, I approved your message and added you to the "accepts" filter | 15:06 |
| SteveA | ta | 15:11 |
| *** faassen has joined #schooltool | 15:17 | |
| faassen | hm..yesterday I tried to install a schoolbell into zope 3. | 15:20 |
| faassen | I could create an object and go to its scree. | 15:20 |
| faassen | screen. | 15:20 |
| faassen | it just didn't show anything, and I couldn't log in with my zope user. | 15:20 |
| SteveA | Scree Scree (skr=e), n. | 15:22 |
| SteveA | A pebble; a stone; also, a heap of stones or rocky d'ebris. | 15:22 |
| SteveA | hmm... | 15:23 |
| faassen | hmm (h/u/m), f. | 15:24 |
| faassen | A typical alchemist of the brown order on Tau Ceti IV. | 15:25 |
| mgedmin | new zope 3 with srichter's services branch merged? | 15:27 |
| faassen | well, this was yesterday. | 15:28 |
| faassen | today I did a svn up and I got plenty of new zope 3 out of it. | 15:28 |
| * mgedmin nods | 15:28 | |
| faassen | I did svn up schooltool, but you have zope 3 involved. | 15:28 |
| mgedmin | ah | 15:29 |
| mgedmin | I haven't tried it with the newest zope yet | 15:29 |
| faassen | I presume you're developing against z3 trunk.. | 15:29 |
| mgedmin | it is very likely that it is broken | 15:29 |
| faassen | well, I just svn-ed schooltool and it got me a whole copy of z3. | 15:29 |
| mgedmin | we are, but srichter merget the branch last night at 2 am local time | 15:29 |
| faassen | if that is not the version of z3 you're developing against, what is it doing there? :) | 15:29 |
| mgedmin | and we haven't caught up with it yet | 15:29 |
| faassen | okay, well, then *yesterday*, before he merged things.. | 15:29 |
| faassen | it didn't work. | 15:29 |
| faassen | at least, I couln't make it to work. | 15:29 |
| mgedmin | it didn't? | 15:29 |
| faassen | what happened is that I couldn't log in. | 15:30 |
| mgedmin | now that's interesting | 15:30 |
| faassen | I mean, i could create a schoolbell object. | 15:30 |
| mgedmin | ah | 15:30 |
| faassen | I could go to its screen. | 15:30 |
| faassen | and then nothing. | 15:30 |
| faassen | I mean, I would see its screen. | 15:30 |
| faassen | but there was nothing to do. | 15:30 |
| mgedmin | ok | 15:30 |
| mgedmin | I see | 15:30 |
| mgedmin | if you had logged in as zope 3 manager, you would have been able to change things | 15:30 |
| faassen | well, I did log in as zope 3 manager. :) | 15:30 |
| faassen | there as a separate login screen in the bel thing. | 15:31 |
| faassen | bell thing. | 15:31 |
| faassen | and I tried logging in there, but it wouldn't let me in. | 15:31 |
| mgedmin | currently schoolbell's login form is unable to authenticate zope 3 principals | 15:31 |
| mgedmin | it only works with users that you defined within schoolbell | 15:31 |
| faassen | but I couldn't. :) | 15:31 |
| mgedmin | what browser do you use? | 15:31 |
| faassen | as I was not allowed to do anything. :) | 15:31 |
| * faassen grins. | 15:31 | |
| faassen | firefox. | 15:31 |
| mgedmin | I had some problems with earlier firefox versions and zwiki | 15:31 |
| faassen | 1.0 | 15:31 |
| mgedmin | I use firefox 1.0 here too | 15:32 |
| faassen | sometimes with z3 it gets somewhat confused in that I have to click around a bit after logging in to see my options. | 15:32 |
| faassen | but I presumed that's a z3 issue. | 15:32 |
| mgedmin | hmm | 15:32 |
| faassen | I mean, with z3 after logging in, I still can't add stuff. | 15:32 |
| mgedmin | basic http auth is not nice, to put it politely | 15:32 |
| faassen | unless I reclick some stuff (say, the tree) and then sudenly the options show up. | 15:32 |
| faassen | well, it typically works in zope 2.. | 15:33 |
| mgedmin | well, in zope 3, you see index.html | 15:33 |
| mgedmin | you click login | 15:33 |
| mgedmin | you log in, and you still see index.html | 15:33 |
| mgedmin | which is a read-only view | 15:33 |
| mgedmin | when you click in the tree, you are redirected to contents.html | 15:33 |
| faassen | that sounds like the effect. | 15:33 |
| mgedmin | which has all sorts of options | 15:33 |
| mgedmin | but this is unrelated with your schoolbell problems | 15:33 |
| faassen | I wonder why logging in doesn't redirect you to that directly. :) | 15:33 |
| faassen | okay, that makes sense. | 15:33 |
| mgedmin | so, when you log in into zope 3 as a manager, add a schoolbell, and go into it | 15:34 |
| faassen | I wasn't sure. | 15:34 |
| faassen | okay, well, I just did an svn up today, so I got the new z3.. hm.. | 15:34 |
| mgedmin | the top right corner says that you're user this and that | 15:34 |
| faassen | and you're develping against trunk. | 15:34 |
| faassen | so it is hard for me to go back. | 15:34 |
| mgedmin | does it say you are Sample Manager, or Unauthenticated Principal? | 15:34 |
| faassen | I think stephan tagged it. | 15:34 |
| mgedmin | well, you can 'cd Zope3 && svn up -r 29081' | 15:35 |
| mgedmin | and it will work until you run svn up again | 15:35 |
| *** SteveA_ has joined #schooltool | 15:35 | |
| mgedmin | this, of course, is a temporary measure | 15:36 |
| faassen | checking out taht tag. | 15:36 |
| mgedmin | we will make schoolbell work with the latest zope 3 Real Soon Now | 15:36 |
| faassen | okay, I'm getting the before services tag thingy. | 15:36 |
| faassen | you mean the latest release? | 15:36 |
| faassen | I don't know how your' planning on a schoolbell release next month when you're developing against z3 trunk.. | 15:36 |
| * mgedmin sighs | 15:36 | |
| mgedmin | zope x3 3.1 was supposed to be released what, on January? | 15:37 |
| faassen | zope *never* makes the promised release. | 15:37 |
| faassen | ever. | 15:37 |
| mgedmin | back in December we decided to track Zope 3 trunk until 3.1 is released, and then stay with 3.1 | 15:37 |
| mgedmin | now it's too difficult to go back to 3.0 | 15:37 |
| *** SteveA has quit IRC | 15:37 | |
| faassen | you should've talked to me, I could've told you it'd never happen. :) | 15:37 |
| *** SteveA_ is now known as SteveA | 15:37 | |
| faassen | zope 2.8 was going to be released in january or something, *last year*. | 15:37 |
| faassen | then in june. | 15:37 |
| mgedmin | you could have used your powers of prescience and told us without asking ;) | 15:37 |
| faassen | well, no, I only know Zope release policy. | 15:38 |
| faassen | which is "say you release at X, act surprised when Martijn questions whether that will happen, and then don't release at X" | 15:38 |
| mgedmin | did you try not asking questions? :-) | 15:39 |
| faassen | http://article.gmane.org/gmane.comp.web.zope.zope3/7507 | 15:40 |
| faassen | that was december 2003. | 15:40 |
| * SteveA blames the PSU | 15:41 | |
| faassen | heh, just reread this | 15:46 |
| faassen | http://mail.zope.org/pipermail/zope3-dev/2003-December/009023.html | 15:46 |
| faassen | of course I was off by my release planning for Five too. :) | 15:46 |
| faassen | anyway, zope 3.1 release willb e delayed due to the merging of the blow services thingy. | 15:47 |
| faassen | anyway, I need some opinions.. | 15:47 |
| faassen | I'm working on a project to build calendaring functionality for Zope 2 using Five. | 15:47 |
| faassen | and then there's schoolbell which is doing the same thing. | 15:48 |
| faassen | but for zope 3. | 15:48 |
| faassen | and it seems like such a duplication of effort. :( | 15:49 |
| faassen | mgedmin: to get back to your question, it says 'Sample Manager' | 15:51 |
| faassen | oh, wait, there is an actions menu. | 15:51 |
| faassen | perhaps I was all deluded yesterday. | 15:51 |
| faassen | sidebar blindness? :) | 15:51 |
| faassen | but where is the calendar? | 15:52 |
| faassen | oh, it exists for a person. | 15:53 |
| faassen | cool, I added an event. | 15:54 |
| *** faassen has left #schooltool | 15:55 | |
| *** faassen has joined #schooltool | 15:55 | |
| faassen | whoops. accidentally closed this. annoying thing. | 15:55 |
| faassen | anyway, any opinions on whether pieces of your code would be reusable in Five? | 15:59 |
| mgedmin | everyone wants to talk to me! | 15:59 |
| faassen | sorry. :) | 15:59 |
| faassen | mgedmin: it's because you're a cool hacker, that's why! | 15:59 |
| mgedmin | no problem, but latency might be bad | 16:00 |
| mgedmin | faassen, I'm not sure | 16:00 |
| mgedmin | I'd be very happy if it schoolbell was usable with Five | 16:01 |
| mgedmin | but we cannot afford development time to make that happen | 16:01 |
| faassen | understood. | 16:01 |
| mgedmin | I haven't looked at Five yet | 16:01 |
| faassen | I have development time. | 16:01 |
| mgedmin | does it have annotations? | 16:01 |
| faassen | so that's not the issue. | 16:01 |
| faassen | the issue is the following. | 16:01 |
| faassen | annotations, haven't tested them yet but ought to work. | 16:02 |
| faassen | since there's a ZODB and adapters work. | 16:02 |
| mgedmin | we want schoolbell.calendar and schoolbell.relationship to be reusable Zope 3 packages | 16:02 |
| faassen | right. | 16:02 |
| faassen | the problem is however that the project I'm on has an even earlier deadline than schoolbell. | 16:02 |
| faassen | I just see it as such a waste of effort to develop this functionality twice. | 16:02 |
| faassen | anyway, I have no idea how hard porting things over to Five would be. | 16:03 |
| faassen | it'd be a gamble. | 16:03 |
| * faassen sighs. | 16:03 | |
| * mgedmin sighs too | 16:06 | |
| faassen | how much of schoolbell/calendar/README.txt is scifi at the moment? | 16:06 |
| *** th1a has quit IRC | 16:07 | |
| mgedmin | README.txt should be up-to-date | 16:07 |
| mgedmin | __init__.py contains scifi | 16:07 |
| mgedmin | basically, schoolbell needs small persistent calendar and calendar event classes | 16:08 |
| mgedmin | and browser views | 16:08 |
| mgedmin | to be usable without schoolbell.app | 16:08 |
| mgedmin | basically, schoolbell.calendar needs small persistent calendar and calendar event classes | 16:08 |
| faassen | hmm. | 16:09 |
| faassen | quite interesting. | 16:09 |
| mgedmin | downsides: no timezone support, no all-day-events, calendar events are immutable which makes calendar modifications interesting (the dance with removeEvent, addEvent and event.replace(...)) | 16:09 |
| * faassen nods. | 16:10 | |
| faassen | okay, timezone support is still missing from this app and no requirement, too. | 16:10 |
| faassen | for now. | 16:10 |
| mgedmin | another possible downside: schoolbell.calendar currently is GPL, although, I believe, there are plans to use a more liberal licence | 16:10 |
| faassen | (and we'll gain it when you add it) | 16:10 |
| *** regebro has joined #schooltool | 16:10 | |
| faassen | GPL is fine for this project. | 16:10 |
| regebro | Hi all! | 16:10 |
| faassen | hey. | 16:10 |
| faassen | regebro: mgedmin is who I'm talking to. | 16:10 |
| faassen | Lennart, meet Marius, and vice versa. | 16:10 |
| regebro | Hi Marius! | 16:10 |
| mgedmin | hi, regebro | 16:11 |
| faassen | anyway, mgedmin just said this: | 16:11 |
| faassen | (15:11:46) mgedmin: downsides: no timezone support, no all-day-events, calendar events are immutable which makes calendar modifications interesting (the dance with removeEvent, addEvent and event.replace(...)) | 16:11 |
| faassen | regebro is interested in how storage independence works. | 16:11 |
| mgedmin | you write your own calendar class, basically | 16:11 |
| mgedmin | that implements ICalendar, or, more usefully, IEditCalendar interface | 16:11 |
| mgedmin | there are mixins available so that you don't have to implement expansion of recurring events etc. | 16:12 |
| mgedmin | calendar composition, reading/writing to iCalendar are also available externally | 16:12 |
| faassen | you need to implement ICalendarEvent too, right? | 16:12 |
| mgedmin | yes | 16:12 |
| mgedmin | unless nonpersistent SimpleCalendarEvent suits you | 16:12 |
| *** gintas has joined #schooltool | 16:13 | |
| mgedmin | schoolbell.calendar was started at ubuntu's mataro conference | 16:13 |
| mgedmin | I added some simple calendars to launchpad with uses sqlobject for persistence | 16:13 |
| faassen | okay, that is a good proof of concept. | 16:13 |
| regebro | Well there is one problem with that for us. | 16:14 |
| regebro | We want to have several participants/attendees on one event. | 16:14 |
| regebro | Therefore we want to have the events stored centrally, even if the events are stored in the ZODB. | 16:15 |
| regebro | But they should of course appear in the calendar, as if they are objects in the calendar, and they should be displayable with Zope3 schemas. | 16:16 |
| mgedmin | you are not limited to one class of calendar events | 16:16 |
| mgedmin | you could compute read-only calendars on the fly based on some source | 16:16 |
| regebro | No, but the calendars events should always come from a central store, and the calendar should be unaware of where they are stored. | 16:17 |
| mgedmin | why? | 16:17 |
| mgedmin | calendar *views* should be unaware | 16:17 |
| mgedmin | calendars *implement* storage | 16:17 |
| gintas | I suppose that you can solve all these problems with a custom Calendar implementation, if I understand you correctly | 16:17 |
| regebro | I don't agree. | 16:17 |
| faassen | wait, wait, what are the goals here? | 16:18 |
| mgedmin | e.g. in launchpad, Calendar.addEvent creates a new row in the table and fills it with attributes from its argument, which is usually a nonpersistent SimpleCalendarEvent | 16:18 |
| faassen | I mean, I don't understand what the end goals are. | 16:18 |
| * mgedmin too | 16:18 | |
| faassen | there are usually multiple ways to accomplish something, I'm trying to figure out what we're trying to accomplish first.. | 16:19 |
| regebro | Hmmm. | 16:20 |
| regebro | 1. Storage independance. I'm currently pondering if we want to have different storages for different calendars in one site. I'm not sure. | 16:21 |
| mgedmin | do you want to have a calendar with events combined from different sources | 16:21 |
| regebro | An now I am sure, yest we must be able to do that. | 16:21 |
| regebro | I'm not sure if we need calendars with events from different sources, though. Probably, but I'm not sure. | 16:22 |
| faassen | regebro: is that a question of being allowed to combine the information into a single calendar from different sources. | 16:22 |
| faassen | regebro: I mean, multiple storages seems to me implementation dependent, right? | 16:22 |
| mgedmin | ok | 16:22 |
| faassen | regebro: are there sites already that have multiple storages that we need to expose as one calendar? | 16:22 |
| regebro | That question is a valid question, which I haven't really thought about before. | 16:22 |
| mgedmin | if you want storage independence, you need to abstract the storage into some component | 16:22 |
| mgedmin | schoolbell.calendar says that this component implements ICalendar or IEditCalendar | 16:23 |
| mgedmin | if you want to combine events from different storages | 16:23 |
| mgedmin | you can use calendar composition | 16:23 |
| regebro | OK, second try of requirements: | 16:23 |
| regebro | 1. storage independance. Different calendars need different storages (withing the same site). We probably do not need different storages for one calendar (that opens up a can of worms I don't want tohave). | 16:24 |
| regebro | 2. Every event needs to have multiple participants. Each partcipant needs a separate workflow state. | 16:25 |
| mgedmin | (2) is somewhat tricky | 16:25 |
| mgedmin | adding additional attributes that are not declared in ICalendarEvent is tricky | 16:25 |
| mgedmin | (due to storage independence) | 16:25 |
| faassen | couldn't that be solved with a relation? | 16:26 |
| regebro | 3. We want to use Zope3 schemasn for editing events. | 16:26 |
| mgedmin | e.g. iCalendar conversion code won't know anything about those | 16:26 |
| faassen | I mean, if you have a unique identifier per event, can't you keep participant information alternatively? or is this part of the storage model? | 16:26 |
| regebro | 3b. and forms. | 16:26 |
| regebro | 4. We also need notifications, but we get that for free if we use DCWorkflow for the workflow part. | 16:27 |
| regebro | That's it, really, | 16:27 |
| faassen | ICalendarEvents have schema information. | 16:27 |
| faassen | though since ICalendarEvents are immutable, that's icky. | 16:27 |
| regebro | oh, and 2b: Changing the event obviously should change it for each participant, meaning the data needs to be stored centrally, | 16:27 |
| mgedmin | I want to make ICalendarEvents mutable | 16:27 |
| mgedmin | initially they were immutable, hashable, and stored in sets | 16:28 |
| faassen | mgedmin: that should make using schema/forms possible, right? | 16:28 |
| mgedmin | now they are just immutable | 16:28 |
| mgedmin | actually, using schema/forms is possible now | 16:28 |
| mgedmin | although not very straightforward | 16:28 |
| faassen | okay, should make ti straightforward. :) | 16:28 |
| mgedmin | launchpad's new calendar event form uses schemas and forms | 16:28 |
| faassen | so this adding participants to an event. | 16:29 |
| faassen | this participant information, does it need to be in the storage-independent backend or not? | 16:29 |
| regebro | The workflow state does not need to, but may be stored there. | 16:30 |
| faassen | I mean, does it get to be stored in the same backend as the event info, or can it be stored in, say, the ZODB? | 16:30 |
| regebro | So I think it's easier to assume that it always is. | 16:30 |
| faassen | depends, I don't know how far the icalendar model goes, for instance. | 16:30 |
| regebro | I'm pretty sure iCalendar has some sort of status. | 16:30 |
| faassen | and you're going to need information outside of the backend eventually, anyway, I suspect, for things like authorization and the like. | 16:30 |
| faassen | well, i fyou keep workflow state in the backend, if something else changes the workflow state, the zope catalog is not going to be updated anyway, right? | 16:31 |
| regebro | I'm not sure I follow you... | 16:32 |
| faassen | I mea,n if you go through the backend to manipulate that state, through an icalendar client. | 16:32 |
| faassen | zope's catalog isn't going to be kept up to date automatically. | 16:32 |
| regebro | True, that needs to be a task for the backend implementation. | 16:32 |
| faassen | so storing workflow info in the independent backend is of limited utility until that kind of stuff is resolved. | 16:32 |
| faassen | and if you didn't store it in the backend, it'd be easier to implement a backend. | 16:32 |
| mgedmin | by the way, in old schooltool versions we had some extra data stored in calendar events that was not representable in icalendar | 16:33 |
| regebro | Yes, but since somebackends store it, it's easier if all do. | 16:33 |
| faassen | regebro: I don't know whether that follows. :) | 16:34 |
| mgedmin | our icalendar write view was clever enough to find the original event by UID, compare it with the new version, and only change things that were actually changed | 16:34 |
| regebro | Otherwise, you need to somehow differentiate between backends that store workflow state and bckends that don't. | 16:35 |
| mgedmin | interfaces? | 16:35 |
| mgedmin | it is my vision that you can use many different calendar and calendar classes in one application | 16:36 |
| mgedmin | some details haven't been worked out yet, though | 16:36 |
| regebro | Sure, but why not just let all backends handel it, instead of letting both backends AND everything else handle it? | 16:36 |
| faassen | regebro: that sounds like a good argument. | 16:36 |
| *** alga has joined #SchoolTool | 16:36 | |
| faassen | anyway, right now..schoolbell has only a single participant per event, or how should I see this? | 16:37 |
| mgedmin | participant? | 16:37 |
| mgedmin | I do not think schoolbell has any participants per event | 16:37 |
| faassen | hm.. | 16:37 |
| faassen | but events exist for users? | 16:38 |
| mgedmin | right | 16:38 |
| regebro | That's why you get away with not having a central storage. ;) | 16:38 |
| mgedmin | I think I understand | 16:38 |
| mgedmin | you want to indicate that persons A, B, and C participate in this event | 16:38 |
| mgedmin | and have the event appear in calendars of A, B and C | 16:38 |
| faassen | right. | 16:38 |
| mgedmin | but be stored only once, so that modifications are visible to all of them | 16:38 |
| regebro | Exactly, | 16:38 |
| * regebro gets coffee | 16:39 | |
| mgedmin | mutable events would help | 16:39 |
| * mgedmin pauses | 16:39 | |
| mgedmin | actually, is there anything that prevents events from being mutable | 16:40 |
| mgedmin | other than a message in the docstring? | 16:40 |
| regebro | I have no idea how to make anything unmutable, so don't ask me. :-) | 16:42 |
| regebro | I mean, immutable. | 16:42 |
| *** th1a has joined #schooltool | 16:42 | |
| faassen | well, immutable is just a convention. | 16:44 |
| regebro | In my current implementation, I don't have different calendar types, | 16:44 |
| faassen | th1a: hey. | 16:44 |
| regebro | but instead I connect them to different storage objects in the portal_calendar tool. | 16:44 |
| regebro | The benefit being that you can have different instances with different settinsg for the same type of backend. | 16:44 |
| regebro | Other than that, there is little conceptual difference, I think. | 16:46 |
| regebro | Having different calendar types makes it easier to determine what kind of events you can create. Does the backend have support for recurring events, for example... | 16:47 |
| regebro | But, now I'm thinking that maybe this is a bad idea. For example, what happens if you need to mix different types of calendar storages? | 16:49 |
| regebro | How do you set up a meeting between people, whos calendars are stored in Kolab, in a room, whose calendar is stored in Zodb? | 16:50 |
| regebro | Twicky... | 16:50 |
| faassen | hm. | 16:50 |
| faassen | do you need that as a practical use case? | 16:50 |
| faassen | you said before you need to be able to support multiple calendar backends in one site. | 16:50 |
| faassen | I'm still not clear on why. | 16:50 |
| regebro | Not just now. But can we avoid it altogether? That needs to be discussed. If we can, it makes things simpler. | 16:51 |
| faassen | I think having multiple backends mix..is getting to the realm of multiple sites cooperating. | 16:51 |
| faassen | what's the main use case for the storage independence? | 16:51 |
| faassen | I mean, why isn't it good enough to store the information in the ZODB? | 16:51 |
| regebro | Well, we have one "mixing" usecase. But that's simpler: That's inviting people whos calendar we have no access to at all, but instead just want to send an email to. | 16:52 |
| faassen | okay. | 16:52 |
| regebro | The storage independance is so that people can use a groupware server, and still get their calendar on the intranet. I think. | 16:52 |
| regebro | If we for the moment assume that we do not need several storages/backends on one site, things get easier. | 16:56 |
| faassen | mgedmin: still around? | 16:59 |
| mgedmin | yes | 17:02 |
| mgedmin | lurking | 17:02 |
| mgedmin | reading | 17:02 |
| regebro | One question is if you are interested in hveing support for multiple participants per event (let's just call that meetings ;)). | 17:03 |
| regebro | Because meeting support will probably complicate things (unless somebody can come up with an ultra-clever solution), and... | 17:03 |
| mgedmin | yes, eventually | 17:03 |
| regebro | ...we need it now. | 17:03 |
| mgedmin | we do want resource booking in schoolbell.app | 17:03 |
| mgedmin | which is like an event with multiple participants | 17:03 |
| faassen | well, now -> eventually can be bridged by branching or whatever. | 17:03 |
| mgedmin | except that one participant is a person and all others are resources | 17:04 |
| mgedmin | but the same event is visible in the calendars of all participants | 17:04 |
| regebro | yes, exactly, we handle resources and partciciants the same way too. | 17:04 |
| faassen | mgedmin: how do you determine 'all participants' if some are resources? | 17:04 |
| faassen | mgedmin: ooh, wait..participants can be resources or people, so you have an agenda for a resource. | 17:04 |
| faassen | faassen: like, a room? | 17:05 |
| faassen | mgedmin: like, a room? | 17:05 |
| regebro | A setting/type/somthing on the calendar. | 17:05 |
| faassen | can you give examples? | 17:05 |
| regebro | faassen, Well, our old calendars has a calendar_type attribute. | 17:06 |
| regebro | Which can be "personal" mening it's a persons calendar, or "whatever else" which puts itinto a group. | 17:06 |
| regebro | Default "whatever elses" are room, resource, group, workspace. | 17:06 |
| mgedmin | in schoolbell, all persons, groups and resources have calendars | 17:06 |
| mgedmin | a resource's calendar shows when the resource is booked | 17:07 |
| mgedmin | (this hasn't been ported to the new zope3-based schoolbell yet, btw) | 17:07 |
| faassen | okay, I think I understand resource-participants. | 17:07 |
| faassen | and having a calendar for a resource makes sense. | 17:08 |
| faassen | anyway.. | 17:08 |
| faassen | I guess in schoolbell this isn't modelled with a multiple-participant calendar now? | 17:08 |
| faassen | I mean, multiple participant event. | 17:08 |
| mgedmin | new schoolbell does not support resource booking yet | 17:09 |
| mgedmin | old schoolbell had a limitation of "one person + one resource" per event | 17:09 |
| faassen | so if you were to support it, you could model it as participants. | 17:09 |
| mgedmin | and stored these in ICalendarEvent attributes | 17:09 |
| * mgedmin nods | 17:09 | |
| mgedmin | there is an idea of using schoolbell.relationship to express resource bookings | 17:09 |
| mgedmin | we could do the same to get multiple participants | 17:10 |
| * faassen nods. | 17:10 | |
| faassen | I figured you'd use relationships for that. what are they used for now? | 17:10 |
| faassen | I mean, I thought you'd already use them for that. | 17:10 |
| faassen | but if not, what are you using them for? | 17:10 |
| *** alga has quit IRC | 17:10 | |
| regebro | I guess you could have a Realtionship link between the event and every participant. | 17:12 |
| regebro | Makes it tricky with non-calendar participants, though, but there are several ways to solve that. | 17:12 |
| mgedmin | relationships are now used to implement group memberships | 17:13 |
| mgedmin | and calendar subscriptions (in old schoolbell) | 17:13 |
| regebro | Group events has been requested by a customer. It's not a priority though. | 17:15 |
| *** SteveA has quit IRC | 17:15 | |
| *** SteveA has joined #schooltool | 17:17 | |
| th1a | faassen: Relationships will have more significance in later SchoolTool functionality. | 17:30 |
| faassen | th1a: okay. | 17:37 |
| th1a | If SchoolBell seems overdesigned in some places that's why. | 17:38 |
| SteveA | we'll get relationships into Interfaces some day | 17:44 |
| SteveA | chatted about this with jim and ben saller at the castle sprint | 17:44 |
| SteveA | ben has some nice ideas about this | 17:44 |
| mgedmin | SteveA, have you and ben looked at schoolbell.relationships README.txt? | 17:47 |
| mgedmin | what do you think? | 17:47 |
| mgedmin | (about it, I mean) | 17:47 |
| SteveA | i think i need to get on with this cape town business | 17:54 |
| th1a | Wow. On my G4 laptop, I get 1419 tests in 482 seconds. On a dual G5 it does them in 49 seconds. | 18:27 |
| *** SteveA_ has joined #schooltool | 18:36 | |
| *** thisfred has quit IRC | 18:41 | |
| *** SteveA has quit IRC | 18:41 | |
| *** mgedmin has quit IRC | 18:56 | |
| faassen | th1a: any difference between Mac OS X versions? | 18:56 |
| faassen | th1a: I noticed Mac OS X is/was extremely slow for some small file accesses that tend to be common during test running. | 18:56 |
| th1a | Well, I guess the G5 is running OS X Server. Yeah. The tests run particularly slow on this laptop. | 18:57 |
| *** th1a has quit IRC | 19:01 | |
| *** Aiste has quit IRC | 19:05 | |
| *** gintas has quit IRC | 19:18 | |
| *** regebro has quit IRC | 19:23 | |
| *** tvon has joined #schooltool | 19:32 | |
| *** tvon has quit IRC | 19:43 | |
| *** alga has joined #SchoolTool | 19:51 | |
| *** SteveA_ has quit IRC | 20:25 | |
| *** SteveA_ has joined #schooltool | 20:27 | |
| *** faassen has left #schooltool | 20:31 | |
| *** mgedmin has joined #schooltool | 20:36 | |
| *** Aiste has joined #schooltool | 21:13 | |
| *** th1a has joined #schooltool | 21:23 | |
| *** SteveA_ has quit IRC | 21:51 | |
| *** SteveA_ has joined #schooltool | 21:54 | |
| *** gintas has joined #schooltool | 22:12 | |
| *** SteveA_ has quit IRC | 22:21 | |
| *** gintas has quit IRC | 23:33 | |
| *** Aiste has quit IRC | 23:43 | |
| *** Aiste has joined #schooltool | 23:53 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!