[Cosmo-dev] including master recordset in feeds

[Brian Moseley]

On 6/12/07, Travis Vachon <travis at osafoundation.org> wrote:
> So let me get this straight:
>
> When I get a collection feed I'll get all of the information I need
> to parse record sets into usable objects, unless the record sets
> represent occurrences or modifications of a recurring event, in which
> case I'll need to make another call to the server?

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?

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

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

> I think Matthew should probably weigh in on whether either of these
> prospects sound acceptable in an AJAX webapp.

it's pretty obvious that we'd rather have fewer requests than more. i
don't think matthew or anybody can name a specific number of requests
that is the threshold between good and bad or usable and not usable.
we have to use the app with real data sets before we can make those
determinations.