Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd)

[Jay Batson <[e-mail]>]

Without (being capable of) expressing a solution preference, I want  
to make sure the authors have sufficient "evidence on the list" that  
-- as part of the basic requirements -- CalDAV must provide an  
acceptable, efficient way for calendaring clients to be capable of  
"offline use using cached calendars & change detection-resolution (on  
reconnect)" mentioned by Julian.

This is, as you're all painfully aware, a difficult thing to do  
efficiently.  There are obvious tradeoffs:
- Good:  Client-side detection of changes, & conflict resolution,  
scales well (by moving the processing to the client);
- Bad:  If designed badly, client-side detection of changes can lead  
to a significant amount of network traffic to obtain necessary  
information from the server to perform the sync / resolution.  There  
are still a significant number of places where CalDAV (and HTTP) are  
going to be used over dial-up where you can't simply assume "free,  
high-speed bandwidth" for all the client/server interactions.
- (Of course, server-side resolution has the opposite problems).
- Version tags are good, and historically many products have been  
built using this method.  The devil-in-the-details question is always  
"How granular should the version tags be?  Per-field, per-object  
(e.g. VEVENT), or per-Calendar?"  Again, with processing / bandwidth  
tradeoffs being the obstacles.

I'm technical enough to know the problem, and need, exists, and have  
been involved at an engineering-management level with two commercial  
products that have solved the problem (MeetingMaker, and Chirp).  So  
I know it can be done; but you're better off not asking me to design  
the solution.  I'm not *that* technical.  :-)

In summary, my thoughts on the requirements:
- Permit changes to DB on either side (client/server) while clients/ 
servers are not connected;
- Ability for one side (client or server; probably client in the  
context of CalDAV) to detect which objects (events, todos, ...) to  
detect modifications made at the other end while disconnected;
- Ability for one side (ditto) to inform the other of changes made  
while disconnected;
- Ability for the side doing the detection/informing to perform user- 
directed conflict resolution, and set the DB on both ends to  
contained the result.
- Do the detection/informing/updating in a bandwidth-efficient manner;

Cheers
-jb

On Apr 18, 2006, at 2:58 AM, Jari Urpalainen wrote:

> On Sat, 2006-04-15 at 10:17 +0200, ext Julian Reschke wrote:
>> Lisa Dusseault wrote:
>>>
>>> On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:
>>>
>>>>> happen, some clients might always do a GET (poor performance) and
>>>>> others might always not (poor interoperability).
>>>>
>>>> Just tell clients to do conditional GETs with the cache  
>>>> validator they
>>>> got upon PUT. The client may not have the same content octet-for- 
>>>> octet
>>>> as the server, but besides that I see no problem (yet).
>>>
>>> Yes, but that's exactly it, there's confusion about what the cache
>>> validator they got upon PUT means, or in what cases the server is
>>> allowed to return it.   Many clients cache calendar items for  
>>> offline
>>> use, and if the server has added its own custom properties or  
>>> modified
>>> data, that may well need to be available offline as well.
>>
>> Currently, there's no way to find out. If this is a requirement,  
>> CalDAV
>> will either have to rely on draft-whitehead-http-etag solving that
>> problem, or come up with its own solution.
>>
>> I'd prefer the former approach, because solving this once and for all
>> HTTP based specs certainly is better.
>>
>> If CalDAV wants to do its own thing, it must make sure that it  
>> doesn't
>> contradict other specs, on which it builds or that servers may  
>> want to
>> implement in parallel with CalDAV. A safe way to do that for now  
>> would
>> be to add a new response header that contains just that piece of
>> information, such as:
>>
>> 	X-Content-Rewritten: "T" / "F"
>>
>> Best regards, Julian
>
> We had similar ambiquities/difficulties with ETags in XCAP, where  
> adding
> new headers were not the preferred way to solve this kind of issues.
> That said, as I have also previously said that 5.3.4 section was
> somewhat difficult to understand and incorrect (rfc2616 reference  
> and no
> clear why reasoning of ETag behavior), I agree with Julian that a new
> X-header or a normative reference to draft-whitehead-http-etag is a
> better way to solve this issue, and certainly the latter option the  
> best
> one.
> br,
> Jari
>
> _______________________________________________
> Ietf-caldav mailing list -- [e-mail]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-------------
Jay Batson
[e-mail]
[phone] (w)
[phone] (m)