[Dev] Re: Recurrence discussion

[Ted Leung]

On May 11, 2005, at 12:12 PM, Jeffrey Harris wrote:

> It seems to me that the options for having the calendar view see
> occurrences of indefinitely recurring events for 20 year in advance  
> are:
>
> 1) Make the view responsible for creating the relevant occurrences  
> (yes,
> I know, thunderous -1's from the list)
> 2) Make the query system responsible for generating the relevant  
> occurrences
> 3) Generate enough events that we're sure the apocalypse will have
> arrived before we run out (I support avoiding theology in Chandler :)
> 4) Don't generate occurrences past a certain point, warn the user
> visually if they're past that point
> 5) Get the model/view contract refined to the point that we can use
> proxy objects and avoid generating occurrences
>
> Does this seem like a complete list?
>
> I've been convinced that 5) is overreaching for 0.6.  1) is inelegant
> and liable to incite insurrection.
>
> 2) seems fine to me, I don't know if it would be OK with Ted.

If you do something like 4), with or without an end date, then all it  
takes for
queries to do this "automatically" is for the query processor to call  
the
method that generates occurrences, at least if you are asking for  
occurrences
that match a date range.

However, if you are doing a query that looks for all occurrences  
related to "Foo",
then you might end up with a situation where the query result should  
contain
occurrences that have not been generated yet.

So, for date range queries, I think it's possible for queries to  
generate occurrences
on the fly.  For other attribute based queries, I'm not so sure.   
Note that the problem
I mentioned above exists even if queries don't try to do the  
generation -- they are just
calling the "make enough occurrences" method.

----
Ted Leung                 Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42