Re: Fwd: Re: Synchronization [Was: Re: CAP: Last Call By MarchIETF: Need Volunteers!]

[Mark Paterson <markp@xxxxxxxxxxx>]

At 10:33 AM 1/18/2002 -0700, you wrote:
> Mark Paterson wrote:
> >
> > >>
> > >>   However, if there is something that we can
> easily add to
> > >> CAP that can help synchronization, we may want to add it.
> On the
> > >> other hand, what I described earlier, on how a CUA can
> have
> > >> basic synchronization, by using query on last modified
> time
> > >> and METHOD:DELETE, should be enough.
> > >>
> > >>   Thus, if there are no objections, I will close
> the issue.
> > >
> > >
> > > I think there are a few issues to consider before closing
> this.
> > >
> > > The key paragraph from the CAP Requirements document is as
> follows:
> > >
> > > "CAP MUST allow synchronization, meaning at a minimum that
> the CUA
> > > is able to find and retrieve new, modified or deleted entries
> for a
> > > given time period. The CUA MUST be able to find out which
> entries
> > > have been added, modified or deleted since it last
> synchronized, in
> > > order to operate in disconnected mode. This requirement may
> be
> > > satisfied using the query requirements already
> defined."
> > >
> > > In other words it must be possible for a sync engine
> (client,
> > > server, whatever) to be able to get the answers to the
> following
> > > three questions.
> > >
> > > 1) Within the given date range what entries are new?
> > > 2) Within the given date range what entries have changed?
> > > 3) Within the given date range what entries have been
> deleted?
> > >
> > > Using a query on last modified time with a date range should
> allow
> > > you to gain answers to 1) and 2). The sync engine just needs to
> keep
> > > track of the time stamp from the last time they asked. Most
> sync
> > > solutions today have a sync context or anchor (or some other
> fancy
> > > name) but when dive in you'll find they all pretty much are
> just
> > > exactly that, the time stamp from the last successful sync. The
> sync
> > > engine need merely enumerate through the results and all the
> IDs it
> > > recognizes are changes and all the ones it doesn't are
> new.
>
>
> > > The only problem I can foresee has to do with instances of
> recurring
> > > entries. If I change the time of an instance of a meeting or
> delete
> > > an instance this will change the recurrence rule for this entry
> and
> > > consequently the last modified time but if I am doing a query
> over a
> > > specific time period  the first instance of the repeating
> may not be
> > > in this time period so will I get it?
>
> Change the RRULE? If you add an EXDATE or EXRULE, it will change
> the VEVENT, but not the RRULE. Or if an instance at the beginning
> or end is deleted - then, yes - you could change the RRULE.
> Both will change the DTSTAMP.

I think you are reading more into what I wrote then I meant. When I
stated that the recurrence rule (not the RRULE) would change I simply
meant something within everything that went into deciding where instances
would end up would change and thus the entry. I should have said
recurrence set as is used in the iCalendar RFC. Sorry for the confusion.
I'm pretty sure I mean the same thing as you.


> This is also why the EXPAND
> property exists.
>
> EXPAND:FALSE - yes, because it is part of the VEVENT and part of
>               
> the VEVENT falls within that range.
>
> EXPAND:TRUE  - no, you will only get the instances of that
> VEVENT
>               
> that fall in that range.

Either way it sounds like a properly tailored CAP-QL query will take care
of what I was worried about. Good.

> > What does DTSTART and DTEND
> > mean in this case? I think this is a basic problem that the people
> > discussing the CAP-QL need to address. If I am trying to get all the
> > entries in a week to populate a week view for example, I need some
> > guarantee that I will get the entries with recurrence rules that
> > cause instances to fall within my range. If the CAP-QL addresses
> > this then I guess the issue for sync will be taken care of as well.

I think it does with RRULE.

> > ...What does DTSTART and DTEND
> > mean in this case?...

I do think that we need to add another note to VQUERY,
this point was brought up before, I don't recall if it was
ever in any version of a draft.

   When performing VQUERYs that use DTEND, the CS MUST calculate:
        
        The effective DTEND for all components that have a DURATION
        property and match on those if they fall into the range
        supplied by DTEND.

   When performing VQUERYs that use DURATION, the CS MUST calculate:

        The effective DURATION for all components that have a DTEND
        property and match on those if they fall into the range
        supplied by DURATION.

Above when you sent:

> > In other words it must be possible for a sync engine (client,
> > server, whatever) to be able to get the answers to the following
> > three questions.
> >
> > ...
> >
> > 3) Within the given date range what entries have been deleted?

It is possible for the CUA to calculate the differences given
the current state of any component in the CUA and the result
of a VQUERY to the CS. So I think the requirement is met.

You don't want the Sync CUA asking the CS about each component it knows
about to see if it has been deleted. This would be a very heavy
operation. You want one call to tell you what's been deleted and I think
it can be done if Calendar CUAs all properly use the METHOD DELETE to
delete things.


> And we need to add text about
> METHOD:DELETE and how that is
> the way to mark somehting as deleted.

It really needs to be a MUST for CUAs.

OK. I think my 1st and 2nd issues have been dealt with here. The only one
remaining is the last one about deleting an instance of a recurring
entry.If the Sync CUA is making a query over a date range how can it be
sure to catch this? It should be able to do something combining the
DTSTAMP and EXDATE I think?

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@xxxxxxxxxxx
http://www.steltor.com