[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