[Cosmo-dev] including master recordset in feeds

[Travis Vachon]

>
> right.
>
> 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
> record?

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  
do so.

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
>> implementation of the JavaScript "getItems(collection)" would
>> 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.

Absolutely :)

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  
path :)

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!

-Travis