[Cosmo-dev] Re: eimml and expanding recurring events

Randy Letness randy at osafoundation.org
Fri May 18 10:48:36 PDT 2007


moving to list...

Bobby Rullo wrote:
> Well, I guess what I meant was dtstart should be missing if it's the 
> same as the recurrence id, just like modification records.
>
> Maybe that's what bcm meant too, but I'm just clarifying.
>
> Also, I don't think we should all those fields back to the client as 
> "missing" if they are inherited, at least for the web ui - it seems 
> like it's unnecessarily chatty. Is there a practical reason to have them?
>
> Also, let's consider having conversations like this on the list - 
> makes it look like we're actually doing stuff :-)
>

So how do you distinguish between modifications and occurrences?

-Randy


previous chatter....
> On May 18, 2007, at 10:38 AM, Randy Letness wrote:
>
>> Bobby Rullo wrote:
>>> To be pedantic, in the uuid, it's really not "dtStart" but 
>>> recurrenceId, right?
>>>
>>> And also, the event record should not have a dtStart field unless 
>>> the dtStart is different than the recurrenceID, right (in which case 
>>> its a modification, not an occurrence.)
>>
>> For modifications, dtStart will be "missing" if it is the same as 
>> recurrenceId.  So an occurrence would not have the field at all?
>>
>> occurrence = no dtstart in event record, but recurrenceId in uuid?
>> Is this accurate?
>>
>> -Randy
Brian Moseley wrote:
> On 5/18/07, Randy Letness <randy at osafoundation.org> wrote:
>> So I finally got around to reading the feed service spec and had a
>> question about how recurring events are represented.  From the spec I
>> gathered that the events are to be expanded on the server, but I
>> couldn't find where it talks about how these "occurrences"  are
>> represented in eimml.  Is this spec'd out or still an open issue?  Now
>> on to the dashboard spec...
>
> here's the proposal:
>
> uuid is <parent uuid:dtstart>
>
> record set
>  note record
>    uuid field
>  event record
>    uuid field
>    dtstart field
>
> everything else is inherited from the master. i suppose technically
> that means we should include all note and event fields, and the fields
> for any other stamp the item has, marked as missing...


More information about the cosmo-dev mailing list