Hi Bobby,
> Yes, but what about occurrences? They aren't explicitly triaged as
> anything because they are not persisted (until someone makes a
> modification) so that's why I said you need to use eventStart so you can
> figure out what occurrences haven't been triaged yet, to stick in "NOW"
Yup, I understand what you were referring to now. The Desktop jumps
through its own set of hoops to handle this, but that approach depends
on periodically updating what occurrences are supposed to be rendered in
the table view; sounds like that's not a good fit for Cosmo so I see
that working with occurrences requires a different approach.
>> The collections I'm imagining a casual collaborator finding a dashboard
>> view useful for aren't likely to contain many (if any) birthdays or
>> annual events, they'll mostly contain tasks and notes and a few events,
>> some of which may be a few months out but are important to see to get a
>> complete view of the project. If you postulate that my posited data set
>> (although I understand we may disagree about how likely this is), does
>> my attachment to seeing all of LATER make sense?
>
> It does make sense. However we cannot dictate how people will use Cosmo
> UI ("Don't use dashboard for collections with birthdays!") so we have
> protect the server from getting hammered.
>
> Maybe Mimi's idea of expanding the date range if there aren't "enough"
> events could work?
Expanding LATER if there aren't "enough" sounds like a reasonable
approach if necessary.
I'm still wondering if you aren't prematurely optimizing this one,
though. It seems like the server has to iterate over all the
indefinitely recurring events (like birthdays) and look at their
start/end times to expand the recurrence rule and check if there's an
occurrence in range. Once those records are paged in, how much extra
processing time does it take to go ahead and send another occurrence
over the wire (maybe a lot more, I really don't know)?
I definitely see that getting a single future occurrence for all ongoing
recurring events would be at least somewhat slower for the server and
slower for the client to process more items, I'm just curious if this is
really a likely culprit for moving from reasonable performance to
hammering the server.
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
