From groupdav@opengroupware.org Wed Apr 2 15:43:54 2008 From: groupdav@opengroupware.org (Ralf Becker) Date: Wed, 02 Apr 2008 16:43:54 +0200 Subject: [GroupDAV] GroupDAV and eGroupWare Message-ID: <47F39BAA.1090504@egroupware.org> Hi all, eGroupWare's current GroupDAV implementation uses an extra WebDAV tree for GroupDAV (beside the one used for file access), with the following structure / collection with 3 groupdav collections /addressbook/ collection with vCards /calendar/ collection with vCals /infolog/ collection with vTodos The collections in the addressbook, calendar, infolog collection contain all entries available to the currently loged in user, with their numerical database id's as names. 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. I'm about to start an improved implementation, which should also solve two other issues: 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, ... b) in eGroupWare every entry is - in WebDAV terms - a collection itself, containing all attached files and other linked entries 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. 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). The same is true with the linked entries, which should show up in the collection of an entry. 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 Or maybe even /ralf/calendar/1.ical --> /apps/calendar/1/self.ical /other/calendar/1.ical --> /apps/calendar/1/self.ical and /calendar/1/links contains a collection with the linked entries and /calendar/1/files contains a collection with attached files Or can the current GroupDav/CalDAV clients directly handle the situation that the entries are collections with something like the self.ical entry? Many questions, I know ;-) Ralf -- Ralf Becker eGroupWare Training & Support ==> http://www.egroupware-support.de Outdoor Unlimited Training GmbH [www.outdoor-training.de] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 (0)631 31657-0 From groupdav@opengroupware.org Wed Apr 2 17:26:12 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Wed, 2 Apr 2008 18:26:12 +0200 Subject: [GroupDAV] GroupDAV and eGroupWare In-Reply-To: <47F39BAA.1090504@egroupware.org> References: <47F39BAA.1090504@egroupware.org> Message-ID: <45816985-DB41-4E32-B2AE-E414EAB54244@opengroupware.org> 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/ From groupdav@opengroupware.org Thu Apr 3 21:38:18 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Thu, 3 Apr 2008 22:38:18 +0200 Subject: [GroupDAV] GroupDAV and eGroupWare In-Reply-To: <45816985-DB41-4E32-B2AE-E414EAB54244@opengroupware.org> References: <47F39BAA.1090504@egroupware.org> <45816985-DB41-4E32-B2AE-E414EAB54244@opengroupware.org> Message-ID: <6BB7264B-F4B2-40A0-A9DD-CE6AB6DDD000@opengroupware.org> On 02.04.2008, at 18:26, Helge Hess wrote: > 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. BTW: what I always wanted to build into OGo/ZideStore is that the user himself can actually configure his GroupDAV tree as he wishes. Maybe that would be something for eG as well ;-) Basically stuff like this: Groupware Query /My Root /Events /My Events events where I participate /WebSite Events events with type 'Website' /Contacts /Customers contacts with tag 'customer' /VIPs contacts with tag 'customer' & 'VIP' etc I think this would be pretty powerful :-) Greets, Helge -- Helge Hess http://www.helgehess.eu/