[Cosmo] revisiting index-but-dont-store for parsed icalendar data

[Brian Moseley]

On 1/11/06, Cyrus Daboo <cyrus+lists.cosmo at daboo.name> wrote:

> If I remember correctly, even if you store iCal data as separate jcr nodes
> etc, the indexer is still used for doing searches, its just that now you
> have to generate a more complex xpath expression  to point to the specific
> node you want to search. i.e. indexing is always required for searching. So
> my suggestion is to fix the indexing/commit problem and leave the jcr node
> structure as-is.

indexing is always required for searching, yes, but there is much less
chance that indexing a resource will fail if we don't have to use the
text/calendar text filter. tho i suppose we still have to do
recurrence expansion.

another benefit to storing at least some of the icalendar properties
as jcr properties is to make the 0.3 home directory browser and atom
feeds more efficient. we're currently using the summary, location,
start date, and end date/duration.icalendar properties there, and we
have to parse them out of the original icalendar stream for each
resource in a collection when viewing that collection in the browser
or constructing a feed for that collection. this is going to be
problematic when people subscribe to calendar feeds and poll them
regularly. caching these small property sets in memory might help, but
we're already having memory usage problems as is.