[GroupDAV] GroupDAV and eGroupWare

[Helge Hess]

Hi Ralf,

On 02.04.2008, at 16:43, Ralf Becker wrote:
> eGroupWare's current GroupDAV implementation uses an extra WebDAV tree
> for GroupDAV (beside the one used for file access)
...
> Helge recommeded to have a structure
> containing the user name, so that eg. different calendars have  
> different
> URL's and not only a different authentication.

yes, this is because conceptually the HTTP resource has some specific  
state. While you can 'Vary' on the authorization header, thats bad  
practice and might defeat good caching (if you put a proxy in between).

Also, if you produce a (virtual) hierarchy for the user, you can  
already apply permissions and such in the subtree (eg only show group  
calendars which the user has access to).
You could also expose virtual collections for calendars the user has  
delegate permissions one.

Eg:
   /adam
     /private calendar
     /groups
       /engineering
       /marketing
     /delegates
       /fritz
       /franz
     /favorite-projects
       /abc123
         /docs
         /notes
         /tasks


> a) we want to have a single WebDAV tree, modelling the data of the  
> whole
> eGroupWare server containing, user homedirs, other documents, events,
> contacts, tasks, ...

I'm not sure I would recommend this (though OGo also does it that way  
[currently]). The problem is that the hierarchy you expose is more or  
less part of the interface the user sees in his native client.
Plus, the native client might potentially attempt to recurse over the  
whole tree (Kontact AFAIK did this), which can be tens of thousands of  
folders.

Do you want the user to see documents and other stuff in Outlook?  
Maybe yes :-) But always keep in mind the user interface of the native  
clients. Eg if you have a 'Projects' or 'Workspaces' folder which  
contains 1.000+ projects or workspaces, this isn't going to work well  
in common clients (in the WebUI you would usually search/sort to  
narrow the set down, in a treeview just everything is visible).

Summary: I'm not sure that the hierarchy exposed towards GroupDAV/ 
CalDAV clients should be the same like the hierarchy exposed to WebDAV  
'file' clients.
I would recommend to write the WebDAV support in a reusable way and  
then setup two distinct hierarchies.


> b) in eGroupWare every entry is - in WebDAV terms - a collection  
> itself,
> containing all attached files and other linked entries

Well, in iCal terms an attached file would be an attachment (either  
embedded, or referenced by URL).
Theoretically you could expose events etc as collections, but this is  
quite likely to confuse native clients (after all they have no concept  
of that). Even generic WebDAV ones.

If you want to expose this subcollection in the UI, I would recommend  
to use a subhierarchy.
Eg /calendar/1223.ics		=> non-collection
    /calendar/1234.ics/contents	=> collection

This way you don't confuse clients (because they won't automatically  
enter the subpath) but you can still open the subcollection  
explicitly, eg in webfolders from the web interface.


> It would make sense, specially for the locking, which is required for
> CalDAV, if a single resource (eg. a calendar event), has only one url
> pointing to it.

I think this just means that your LOCK manager needs to work on your  
internal IDs, I don't think there is a problem with multi-URLs here.  
Map to your internal ID and then retrieve/manage the lock token.

>  But a calendar events with multiple participants has to
> show up in the calendar collections of multiple participants (which  
> have
> of cause different rights on it).

Well, why would that be a problem? The event would show up in:
   /userA/calendar/1.ics
and
   /userB/calendar/1.ics
Each client will (usually) only see one user-hierarchy.

LOCKs should be no problem either, see above.

> The question is now, is it ok that a collections contains urls  
> pointing
> to different parts of the tree, eg. (scheme+host parts are removed)
>
> /ralf/calendar/1.ical --> /calendar/1.ical
> /other/calendar/1.ical --> /calendar/1.ical

This is not expected to work. Its a hierarchy, not a graph :-) The  
thing which might possibly work is a redirect. Eg:

   PROPFIND /ralf/calendar/
   => 1.ics

   GET /ralf/calendar/1.ics
   HTTP/1.0 301 Moved Temporarily
   Location: /calendar/1.ics

   GET /calendar/1.ics
   HTTP/1.0 200 OK

But I wouldn't expect that this works very well with real world  
clients, they just dont expect it (though *I* would tend to support  
this :-).

Summary: make it a tree with distinct subsets. This works best when  
the collections are 'virtual' folders which do the right thing for the  
specific user hierarchy.


Sidenote:
 From a HTTP PoV its not a problem to have one HTTP resource reachable  
by many URLs.
But it becomes a problem in offline mode, since the user might tweak  
one representation. In another folder another (then outdated)  
representation might exist.
Hm, probably the content-location header would help here, but then I  
do not expect many clients to support that. [hm, I should support  
it :-)]


> and /calendar/1/links contains a collection with the linked entries
> and /calendar/1/files contains a collection with attached files

That would be OK, if /calendar/1 itself is NOT a WebDAV collection.  
Though a single entry point is probably more convenient. See above.

The question is the actual usecase, that is, *why* would you want to  
expose '1' as a WebDAV collection?

And again: in the case of ICS, links might be URL tags of the ICS  
file, and the files would be ATTACH ones (best with a URL reference).


> Or can the current GroupDav/CalDAV clients directly handle the  
> situation
> that the entries are collections with something like the self.ical  
> entry?

You can expect most clients to be completely naive and not support  
such stuff. Its important to make a sane hierarchy :-)

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/