[Cosmo-dev] including master recordset in feeds
travis at osafoundation.org
Tue Jun 12 13:33:56 PDT 2007
> the reason this is an issue is that if we include both the master and
> the (modification | occurrence), how do you know that only the
> (modification | occurrence) is supposed to be displayed, but not the
> master? if you can unambiguously determine that, then we don't need to
> change anything at all. is identifying an item as a master as simple
> as detecting the presence of an rrule and/or rdates in its event
Right now we handle this in three steps:
First, we go through all of the entries in the feed. If they
represent a master item, we parse them into an Item object and put
them into a hash keyed by UUID, if they represent a modification
(which we figure out by looking at the UUID) we store them for later.
Next, we go through modifications and occurrences and translate them
into NoteOccurrences, keeping track of which master items we used to
Finally, we remove the master events we used from the original hash,
pack whatever's left into an array, and send it up to the UI.
This might not be the most efficient way to do things, and it assumes
that if we see an occurrence or modification we definitely don't want
to display the corresponding master event. This seems pretty
unambiguous to me for our needs, but it does require a client to have
this knowledge about the protocol.
Come to think of it, I think your suggestions (detecting an rrule or
rdate) would work perfectly as well. Any thoughts Bobby?
>> Also, a naive
>> probably make a call to the server for each occurrence, resulting
>> in n
>> +1 client-server round trips, where n is the number of occurrences or
>> modifications in the collection feed. Even with caching this seems
>> unnecessarily expensive.
> you don't have to be naive. you can certainly tell from an
> occurrence's uuid whether or not you have its master available. once
> you've loaded the master for one occurrence, there is no need to load
> it again for another occurrence of the same master.
This still leaves us with (# of recurring items) + 1 round trips, of
course. The problem is compounded by the fact that each part of the
ui (that is, the calendar and the list view) is responsible for
getting and maintaining its own data. I'm not sure exactly the reason
behind that decision, but Matthew or Bobby could probably elucidate.
I do also appreciate that caching will likely improve performance
here, but we're still talking about full client server round trips.
>> It would make more sense to me if a collection feed always returned
>> all of the master items, which contained links to the "expanded"
>> version of themselves.
> this is actually true. every master item in a collection feed has a
> link with rel "expanded". but in this discussion we're talking about
> dashboard feeds and collection feeds bounded by a time-range, both of
> which are pre-expanded, so this doesn't really make sense.
Yeah, I was assuming here that we would stop including the occurrence
and modification entries in the collection feed if we went down this
To be honest, from a pure protocol point of view, this seems cleaner,
relegating occurrence and modification entries to the "expanded"
feeds. That said, from my end I'd still much rather have things the
way they are now!
More information about the cosmo-dev