Recurrence In The Cosmo Calendar UI

Jeffrey Harris and I had the following discussion on 9/15/2006. I initiated the conversation to gain some insight into how Chandler handles recurrence to help me do the same in Cosmo. Enjoy.

[10:28am]JeffreyH joined the chat room.

[10:28am]reid [osaf] joined the chat room.

[10:28am]reid [osaf] left the chat room.

[10:28am]• JeffreyH is trying to do too many things at once, so may be a little slow

[10:28am]bobbyrullo : that's ok

[10:29am]bobbyrullo : so these other cases, you are sure I can ignore them?

[10:29am]JeffreyH: There's change past occurrences

[10:30am]bobbyrullo : heh right

[10:30am]JeffreyH: but no one ever uses that, as far as I can tell

[10:30am]bobbyrullo : let's pretend that doesn't exist right now

[10:30am]bobbyrullo : so the recurrence spec in icalendar is large.

[10:30am]bobbyrullo : and I don't have it all absorbed et

[10:30am]bobbyrullo : but my understnading is that

[10:31am]bobbyrullo : changing ALL events is easy: you just change the master event

[10:31am]bobbyrullo : changing a single event is a little trickier

[10:31am]bobbyrullo : er, a single instance

[10:31am]JeffreyH: Well, there are complications

[10:31am]bobbyrullo : right

[10:32am]JeffreyH: does a change to all (or this and future) apply to items that have already been modified?

[10:32am]bobbyrullo : one way to handle is to make an exception and create a new detached VEVENT?

[10:32am]bobbyrullo : oh you mean future exceptions?

[10:32am]JeffreyH: In chandler, we distinguish between generated occurrences (or just occurrences) and modifications

[10:32am]JeffreyH: yeah, exceptions == modifications

[10:32am]bobbyrullo : rigt

[10:33am]bobbyrullo : so how does chandler handle it? do future events that have already been modified get the new mods/

[10:33am]bobbyrullo : ?

[10:33am]JeffreyH: Right now, no. In the future, the idea is to have per-attribute mods,

[10:33am]JeffreyH: so if I changed one occurrence's start time

[10:33am]JeffreyH: a change to all titles would still affect it

[10:34am]bobbyrullo : gotcha.

[10:34am]bobbyrullo : how would that be modelled in iCalendar?

[10:35am]bobbyrullo : you'd have to go and manually modify each VEVENT

[10:35am]bobbyrullo : each VEVENT's title

[10:35am]JeffreyH: Well, no

[10:35am]bobbyrullo : ok

[10:36am]JeffreyH: icalendar's model is per attribute, too

[10:36am]bobbyrullo : oh really

[10:36am]bobbyrullo : so that's good then

[10:36am]JeffreyH: a modification is a vevent with a matching uid and the appropriate recurrence-id. Any attributes not set on that modification are supposed to be inherited from the master

[10:37am]bobbyrullo : I see

[10:37am]bobbyrullo : that's sane

[10:37am]JeffreyH: So, in icalendar land, changing things is actually pretty easy

[10:37am]JeffreyH: but modelling what's been changed internally is complicated for us

[10:38am]bobbyrullo : how come

[10:39am]bobbyrullo : it seems that right now (I'm playing with chandler .7 a 3) modified events become completely detached

[10:39am]JeffreyH: Yup

[10:39am]bobbyrullo : and the "all events" is always grayed out

[10:39am]JeffreyH: Yup

[10:40am]bobbyrullo : is that all that's expected for beta

[10:40am]JeffreyH: Although there's no particular reason for greying out all events

[10:40am]bobbyrullo : yeah, except for user confusion potentially

[10:40am]JeffreyH: I'm not sure, grant's working on recurrence these days

[10:40am]bobbyrullo : it's technically the easiest

[10:40am]bobbyrullo : oh really

[10:40am]bobbyrullo : ok

[10:40am]JeffreyH: But he's on vacation today

[10:40am]bobbyrullo : ah

[10:40am]JeffreyH: so I'm still a good person to talk to

[10:40am]JeffreyH: anyway, the model for recurrence currently in chandler

[10:40am]bobbyrullo : I remember AGES ago one of my todos's was "talk to jefferey about recurrnce"

[10:40am]bobbyrullo : I don't even think I knew who you were

[10:41am]bobbyrullo : I was still in NY

[10:41am]JeffreyH: heh

[10:41am]JeffreyH: is that THIS (individual) changes are still attached, but no attribute changes are propagated to it

[10:41am]JeffreyH: so, for instance, if I remove recurrence, that modification goes away

[10:41am]JeffreyH: Or if I delete the whole series

[10:42am]JeffreyH: but our current shortcut for THISANDFUTURE modifications is we make the new series a completely new VEVENT, with a different icalUID and everything

[10:42am]JeffreyH: so we don't have to worry about chains of modifications that apply to multiple events

[10:42am]JeffreyH: I think we'll probably stick with that

[10:42am]bobbyrullo : I see

[10:42am]JeffreyH: the use cases for keeping them semantically connected are pretty week

[10:42am]JeffreyH: weak, I mean

[10:42am]bobbyrullo : yeah

[10:42am]bobbyrullo : I think they'

[10:42am]bobbyrullo : theyre pretty month.

[10:43am]bobbyrullo : so here is how I am hearing we can handle things (emulating what y'all do right now)

[10:43am]bobbyrullo : 1) for changing all events (if we even support that) - easy, just edit master event

[10:44am]bobbyrullo : 2) for editing this and future: Change end date of original series, create new series which starts on mod date

[10:44am]JeffreyH: yup

[10:45am]bobbyrullo : 3) for editing a single: Create an exception (is that the term for when a thing doesn't occur when it should?) and create a new event with new UID on a new date?

[10:45am]JeffreyH: so, part of the complication is that Chandler's UI first accepts a change to an event, then pops up a dialog to determine if that change is for future or just this event

[10:45am]JeffreyH: I call them modifications, to contrast them with OO exceptions, but whatever, everyone else calls them exceptions.

[10:46am]JeffreyH: NOT a new uid

[10:46am]JeffreyH: same UID, different recurrence-id

[10:46am]bobbyrullo : I only say exceptions because i thought they are called that in the Icalednar model

[10:46am]bobbyrullo : ah

[10:46am]bobbyrullo : so if I have a daily event

[10:46am]JeffreyH: Yup, I know what you mean, it just never occurs to me to call them that, overloading exception seems problematic when you're working with an API

[10:47am]bobbyrullo : I hear you

[10:47am]bobbyrullo : and I move one occurence an hour earlier, that occurrence is STILL attached to the original series?

[10:48am]bobbyrullo : my playing with chandler doesn't seem to bear out that reality

[10:48am]bobbyrullo : as changing a title in the orig. series doesn't change the title on that moved event

[10:48am]JeffreyH: right, because we don't have per attribute exceptions

[10:49am]JeffreyH: but if you delete the whole series, or remove recurrence, that exception goes away

[10:49am]bobbyrullo : heh

[10:50am]bobbyrullo : so icalendar has these per attribute mods, but chandler does not (yet)

[10:51am]JeffreyH: right

[10:51am]bobbyrullo : so when your code translates the data model from chandler --:> icalendar you get an exception overriding all the parent's properties

[10:52am]bobbyrullo : or else your series would appear different in chandler than other icalendar clients

[10:54am]JeffreyH: Right.

[10:54am]JeffreyH: We just go ahead and export everything for a modification (exception)

[10:54am]JeffreyH: (sorry, back now, bobbyrullo)

[10:55am]bobbyrullo : hmmm.

[10:55am]bobbyrullo : if I could do better than that should i?

[10:55am]JeffreyH: Yeah, we'll do better soon, too

[10:55am]bobbyrullo : ok

[10:56am]bobbyrullo : so how do you handle deletes?

[10:56am]JeffreyH: so, the deal with not knowinig what kind of change to make is a little tricky

[10:56am]JeffreyH: we handle it with a proxy wrapper around chandler items

[10:57am]JeffreyH: which gets into a whole different debate, our detail view expects real items, not proxies

[10:57am]JeffreyH: so I implemented our recurrence so each occurrence is its own item

[10:57am]JeffreyH: which isn't really a good way to do things

[10:57am]JeffreyH: to avoid using proxies

[10:57am]JeffreyH: but then we used proxies anyway

[10:57am]bobbyrullo : this is easy for us. We don't HAVE real items

[10:57am]bobbyrullo : it WILL be hard for us

[10:57am]bobbyrullo : perhaps

[10:57am]JeffreyH: well, you might have something like them

[10:58am]bobbyrullo : well, yes and no

[10:58am]bobbyrullo : our "items" are disconnected from the real datastore

[10:58am]bobbyrullo : obviously

[10:58am]JeffreyH: right

[10:58am]bobbyrullo : being that we're a browser, and our data store is far away

[10:59am]JeffreyH: well, so, in your calendar you'll presumably have canvas objects which refer to data objects of some sort

[10:59am]bobbyrullo : and the items are little more right now than DTOs (data transfer objects)

[10:59am]bobbyrullo : sure

[10:59am]JeffreyH: those data objects in chandler are full fledged items if they're occurrences

[10:59am]bobbyrullo : how do you store an infinite number of occurrences ?

[10:59am]bobbyrullo : with the proxies I guess

[10:59am]JeffreyH: for you all, I'd make each data object be the master recurrence object, plus a little bit of information pointing you to what occurrence you're interested in

[11:00am]bobbyrullo : hmmm

[11:00am]JeffreyH: We generate occurrences on the fly

[11:00am]JeffreyH: which is ugly

[11:00am]bobbyrullo : is it important to know if you are the first event?

[11:00am]bobbyrullo : perhaps, perhaps not

[11:00am]bobbyrullo : yeah, all events could be the master I suppose

[11:00am]JeffreyH: well, generating on the fly isn't ugly, it's persisting what you've generated that's ugly

[11:00am]JeffreyH: well, modifications maybe not

[11:01am]JeffreyH: but your API for working with recurring objects should abstract away the modification-ness of modifications

[11:01am]JeffreyH: s/should/could/

[11:01am]JeffreyH: I don't think it really matters if you're the first event

[11:02am]JeffreyH: there's lots of code in chandler that fiddles around with whether something's the first

[11:02am]JeffreyH: but since we got rid of chains of THISANDFUTURE modifications

[11:02am]JeffreyH: and then made it so the first occurrence wasn't ever rendered (that's a long story, having to do with item requirements in the detail view again)

[11:03am]JeffreyH: being first isn't important

[11:03am]bobbyrullo : I wanna be first

[11:03am]bobbyrullo : !

[11:03am]bobbyrullo : could you make this sentence a little less meta-physical: "but your API for working with recurring objects should abstract away the modification-ness of modifications"

[11:04am]bobbyrullo : not sure whatcha mean by that

[11:05am]JeffreyH: you could have modifications be totally separate objects

[11:05am]JeffreyH: with a link to the master (so the master knows to go get that modification instead of using a generic generated occurrence)

[11:06am]JeffreyH: or you could always hand canvas objects the master and what date they're interested in

[11:06am]JeffreyH: and whether there's a modification involved wouldn't be important

[11:08am]bobbyrullo : I see whatcha

[11:08am]bobbyrullo : mean

[11:08am]bobbyrullo : I think I have enough to work on

[11:09am]bobbyrullo : you've been very helpful

[11:09am]bobbyrullo : if you don't mind, I'd like to post this discussion

[11:09am]bobbyrullo : on my wall.

[11:10am]JeffreyH: on your wall?

[11:10am]JeffreyH: Sure, whatever

[11:10am]JeffreyH: I think there are a few other gotcha... like for instance, if you change all occurrences start times, and you have a few exceptions, you have to change those exceptions recurrence-ids (even if you leave their start times the same)

[11:11am]JeffreyH: deleting is actually pretty simple, just add an exdate or change the rules UNTIL to stop just before that event

[11:30am]bobbyrullo : cool

[11:30am]bobbyrullo : thank JeffreyH!

[12:02pm]JeffreyH left the chat room.