[Ietf-caldav] Alternative to splitting out components

[Lisa Dusseault]

>
>>   - Attach conversations to events
>
> What are 'conversations' in this context?

A pretty fuzzy Chandler concept -- just assume it's a fair amount of 
text, possibly a fair bit larger than the iCalendar data itself.

>
>>   - Keep very old events around --> keep very large calendars
>
> Large calendars would not be a problem (* see below for a comment on 
> this): in theory it would be possible for a caldav server to disable 
> GET and PUT on the calendar file resource and only allow PROPFIND, 
> REPORT and PATCH as the means to access and change components. That 
> would force the client (authors) to think about exactly what they want 
> and only ask for that.

Ahhh, but now you see you're going down the path of reinventing 
mechanisms to handle sub-sections of a calendar, rather than using the 
mechanisms the protocol provides for you.  We could possibly define 
simpler mechanisms than GET, PUT, and remembering ETags for each event; 
but it wouldn't be as well-tested and it would become increasingly 
unlike HTTP.

>
>>   - Good multi-author coordination changing different events, or even
>> changing different properties of same event --> shared calendars like
>> meeting rooms
>
> This is presumably an issue with lock contention when sharing a 
> calendar?

Not if single resources are locked.  Assuming the client even locks a 
single event (it doesn't need to if it does things properly) that event 
lock wouldn't conflict with other event locks on the same calendar.  
(And more advanced clients still have the choice of obtaining multiple 
locks.)

>
>>   - Fast browsing to "what's on this user's calendar today"
>
> A report can easily handle that for either model.

Why redefine what PROPFIND already does in the multi-resource model?  
I'd rather minimize the new things we need to design.

>
>>   - Selective permissions
>
> Do you mean per-component ACLs? i.e. a user has read access to one 
> component, but not another in the same calendar? I really wonder what 
> the benefit of that is over just having per-calendar ACLs. Certainly 
> in the case of IMAP per-mailbox ACLs are sufficient. The thought of 
> having per-message ACLs is scary - and I think that boils down to the 
> user experience - per-message ACLs would really make the UI too fuzzy 
> in terms of maintaining a clear distinction between what might be 
> shared or not. I think the same would apply to events in calendars.

It wouldn't be required for all clients, but it's certainly a Chandler 
use case.

>
>> IOW, I think it is in fact simple, but too simplistic.
>>> We could consider another way to accomplish the client simplicity you
>> propose at the cost of server complexity: require the server to 
>> provide
>> *both* views.  I'm worried that this would require not only more 
>> server
>> work but also have some conflicts that we'd have to figure out how to
>> deal with.  E.g. it doesn't really help multi-author scenarios if the
>> single-file calendar is always being locked by slow clients.
>
> I think that is pretty much what I proposed before with the Level 
> 1/Level 2 type behaviour, but now think Level 2 is too complex.
>
> My main concern right now is really with the on-the-wire complexity - 
> I want to keep the requests to a minimum and I think the 
> one-resource-per-calendar does do that. Can you explain how you see 
> the on-the-wire-behaviour for doing things like sync'ing an entire 
> calendar with the current model?

Don't forget that a PROPFIND can get a named property -- like the ETag 
-- for every item in a collection.  Here's how:

C-->S
PROPFIND /repository/lisa/calendar/ HTTP/1.1
Depth: 1
Content-type: text/xml

<?xml version="1.0" encoding="utf-8"?>
   <D:propfind xmlns:D="DAV:">
     <D:prop>
       <D:getetag/>
     </D:prop>
   </D:propfind>

[Now client compares the resulting list of ETags/URLs to the table of 
locally stored ETags/URLs.  For each new ETag, pipeline:]

C-->S
GET /repository/lisa/calendar/new-event-on-server HTTP/1.1

[Don't forget to store the new ETag for each of these.  Now client 
compares the resources flagged as "dirty" locally, if there are any, 
"dirty" meaning local changes were made:]

C-->S
PUT /repository/lisa/calendar/new-event-on-client HTTP/1.1
...

[Again don't forget to store the new ETag in the response to each of 
these.]


In this example I oversimplified the problem of what to do with an 
event that has changed both on the server and on the client, if the 
client made changes while offline and chose not to lock the file.  If 
the client allows offline changes it has to have additional logic to 
deal with conflicts.



>
>
>
> (*) There are obviously tradeoffs in the server performance of 
> single-resource-per-calendar vs single-resource-per-component models - 
> I am comparing this to the similar case of mailstores that use one 
> file per-mailbox or one file per-message models. Some operations 
> perform better in each of the different models. Also things like 
> backup/restore perform better for the per-message as opposed to 
> per-mailbox model. But that level of detail in server implementation 
> should not be a consideration.
>
> -- 
> Cyrus Daboo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5485 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-caldav/attachments/20040820/8576d11c/attachment.bin