[#3032] WebDAV / iCal support for Kronolith
| Summary | WebDAV / iCal support for Kronolith |
| Queue | Kronolith |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Resolved |
| Priority | 2. Medium |
| Owners | Jan Schneider <jan (at) horde (dot) org> |
| Requester | d (dot) bussink (at) student (dot) utwente (dot) nl |
| Created | 11/24/2005 (899 days ago) |
| Due | |
| Updated | 05/01/2008 (10 days ago) |
| Assigned | 12/27/2005 (866 days ago) |
| Resolved | 04/15/2008 (26 days ago) |
| Attachments | horde_webdav_patches.tar.gz  webdav_ical.patch |
| Milestone | 2.2 |
| Patch |
there are open tickets for the other share apps with webdav supportYes, if this has been consistently applied to all share-apps in the meantime.State ⇒ Resolved
Taken from
Saying yes. Please re-open if no, but for individual webdav bugs, please open new tickets.So with the new level for share owners, this can be closed, right?I decided to indeed add another directory level for the share owners. This is in line with the recent discussion about allowing users to specify their own share names, which has also been part of this request, see comment#28and#30.This has to be applied to other share apps with webdav interfaces too.
This is considered complete. The new path layout and whether it is really necessary has yet to be decided before the Horde 3.2 release.This is not a support forum. If you have questions, ask on the mailing list. If you want to sponsor development, go to the consulting or bounty pages.I have a simular situation. This function is really important to me. I am forced to run Thunderbird and Lightning is provides the ability to accept .ics meeting requests which then are added to Lightning. However, I have no way to MLSync my Treo Palm 700P. Horde / Kronolith provides this function.
I have been searching to any documentation that would discribe how to setup Horde and Kronolith to be able to do this is. I have setup using CVS FRAMEWORK_3 branch and trying to apply these patches but the patches only partially succeed. I have set up CVS HEAD and thought from what I have been able to find to read that these functions have been added to HEAD. I am interested in understanding whether or not the patches are supposed to be applied to HEAD or not. Look in the patches it does not appear that the patches support the CVS HEAD.
I would be happy to do a detail document if someone would be able to initially guide through.
Thanks for all of the efforts being put in to this project.
--Steve
>> Finally committed, thanks a lot.
>
> Maybe I don't understand CVS (I use SVN for all my projects), but I
> can't seem to find these patches in CVS. For that matter, I can't
> find the 'webdav.php' I've seen mentioned as a basis for DAV ops in
> Horde. I just did a 'cvs co -r HEAD' on horde, kronolith, framework,
> etc.
>
> Do you have a separate repository where this has been committed?
> We're evaluation Horde vs. Zimbra, and I prefer Horde, but we really
> need remote (iCal or DAV) calendaring working.
You can't be looking very hard, then :)
framework/RPC/RPC/webdav.php
http://cvs.horde.org/co.php?r=1.16&f=framework%2FRPC%2FRPC%2Fwebdav.php
Graeme
> Finally committed, thanks a lot.
Maybe I don't understand CVS (I use SVN for all my projects), but I can't seem to find these patches in CVS. For that matter, I can't find the 'webdav.php' I've seen mentioned as a basis for DAV ops in Horde. I just did a 'cvs co -r HEAD' on horde, kronolith, framework, etc.
Do you have a separate repository where this has been committed? We're evaluation Horde vs. Zimbra, and I prefer Horde, but we really need remote (iCal or DAV) calendaring working.
Is there any body who have files webdav.php and webdavinc.php?
I'm not find them on the CVS.
Finally committed, thanks a lot.
The new paths still need to be done.
We will probably add another directory level with the share owners under kronolith/, the url for my birthday calendar would be rpc.php/kronolith/jan/birthdays.ics then.This allows to create new calendars through DAV without running out of unique share names because we could prefix the share name internally with the user/owner name then. E.g. if I create the calendar above its share name will be jan@birthday.ics or similar, and when showing the share through the DAV interface, jan@ will be removed again.
A bit of black magic, but it allows to create calendars without risking name clashes and still having nice URLs.
State ⇒ Assigned
Assigned to
New Attachment: horde_webdav_patches.tar.gz
Hereby a number of patches against the CVS tree:
horde_webdav_patches/framework_rpc.patch
horde_webdav_patches/kronolith_api_put.patch
horde_webdav_patches/horde_rpc.patch
These three patches are for the basic iCal/WebDAV support. The first one patches the framework to include calling functions for PUTting files through the registry. The second one adds this function for Kronolith. The third patch is a patch for the rpc.php file. It changes the file so it doesn't read the input for webdav functions, this is handled through a stream in the PEAR HTTP_WebDAV_Server (this took me two hours before I found why it went wrong...).
horde_webdav_patches/kronolith_api_put_with_new.patch
horde_webdav_patches/kronolith_calendars_id.patch
These two patches add some extra functionality. The first one creates a new calendar if a PUTted file has a name for which no calendar exists yet. The second patch allows for supplying an identifier for a new calendar. This identifier is used for naming the calendar file, I didn't like the hexadecimal filenames, therefore I created this.
The first bunch of patches are really necessary, the second bunch is not really necessary, but I think they can be useful.
Hereby a number of patches against the CVS tree:
horde_webdav_patches/framework_rpc.patch
horde_webdav_patches/kronolith_api_put.patch
horde_webdav_patches/horde_rpc.patch
These three patches are for the basic iCal/WebDAV support. The first one patches the framework to include calling functions for PUTting files through the registry. The second one adds this function for Kronolith. The third patch is a patch for the rpc.php file. It changes the file so it doesn't read the input for webdav functions, this is handled through a stream in the PEAR HTTP_WebDAV_Server (this took me two hours before I found why it went wrong...).
horde_webdav_patches/kronolith_api_put_with_new.patch
horde_webdav_patches/kronolith_calendars_id.patch
These two patches add some extra functionality. The first one creates a new calendar if a PUTted file has a name for which no calendar exists yet. The second patch allows for supplying an identifier for a new calendar. This identifier is used for naming the calendar file, I didn't like the hexadecimal filenames, therefore I created this.
The first bunch of patches are really necessary, the second bunch is not really necessary, but I think they can be useful.
> I can seperate the functionality into two different patches against
> the latest cvs snapshot, where only the second provides the
> functionality mentioned above (the last two points).
That would be great, because I'm indeed inclined to reject the two latter points. But I might get convinced.
Just to summarize what my current version does:
- List a file named calendar_name.ics in the PROPFIND listing
- Being able to fetch this file with a GET
- There is automatically a file for a calendar created for that user with the
same username if it doesn't exists yet. This is the same behaviour as
the web interface.
- Being able to PUT a file
- When this file doesn't exists, a new calendar is created with the given
name and datatree_name
- The web interface for adding a calendar also allows for setting the
datatree_name (I named it Identifier), zo pretty urls are possible (no long
hex codes). This checks for double id's e.d. and only allows numbers,
characters, '-' and '_'.
The last two points are maybe not something that is appropriate for Kronolith. The main reason I made these changes is that I primairly use external application and only the web interface for when I'm not on a system where I work regurlarly. This is also the case for the study association, who will also be using this patch.
I can seperate the functionality into two different patches against the latest cvs snapshot, where only the second provides the functionality mentioned above (the last two points).
> The PUT function calles the import function in the api so the
> calendar data is imported. I've chosen not to directly call the
> input, mainly because it could work for kronolith, but I can imagine
> that other applications cannot work with the import directly. This is
> mainly because the totally different concepts that are used in the
> import and put. PUT is based on a path with some file content, which
> is radically different from importing a certain element in a
> application. For this reason, I think the usage of an extra function
> is legitimate.
Makes sense.
> Although I use the import function directly now, I think it would be
> nicer to use a seperate function for importing a iCalendar file in
> total. This is because a PUT with a iCalendar file currently results
> in the entire calendar being deleted and afterwards the elements from
> the file are added again. This is because otherwise no elements can
> be deleted (import only allows for adding). Another disadvantage is
> that every entry is therefore seen as being modified on a PUT. A
> better solution would be a seperate function that check for each
> element if it has changed / added / deleted and modifies these
> entries accordingly.
I think we can live with this disadvantage. GroupDAV and CalDAV probably deal with that situation anyway.
I added a PDF to http://wiki.horde.org/Doc/Dev/DAV with slides from a meeting with the GroupDAV guys on this year's LinuxTag, in case you're interested.
> this. I can add files with the name calendar.ics in the listing of
> kronolith (so you get something like the following):
That's my favourite solution too.
> For adding calendar's with WebDAV, it should be simply creating a
> calendar with the (part of) the file name (so calendar_name for
> calendar_name.ics). After this, the data of the file can be imported
> (or does the import already create a new calendar if it doesn't
> exists?).
No, I don't think we should support adding of calendars through WebDAV. It's not such a burden to request users to create calendars first before using them from an external client.
> Just another question, how mature is the CalDAV support, or is it in
> it's current state nothing more that getting events?
It doesn't exist yet. It's based on WebDAV, that's why I started implementing that first. Next would have been GroupDAV, and CalDAV at the last because it's the most heavy-weight DAV solution.
Today I've made some new changes, which implement the first solution I presented in my last comment. It adds in the file listings next to the directory representing a calendar, also a file with the same calendar name and the .ics extension.
Currently it uses the exportCalendar api function which was already created for ics.php. For PUT it uses a system where the _kronolith_put function is called through the registry. This means that other applications, such as turba, can also use a _turba_put function in their api.
The PUT function calles the import function in the api so the calendar data is imported. I've chosen not to directly call the input, mainly because it could work for kronolith, but I can imagine that other applications cannot work with the import directly. This is mainly because the totally different concepts that are used in the import and put. PUT is based on a path with some file content, which is radically different from importing a certain element in a application. For this reason, I think the usage of an extra function is legitimate.
Although I use the import function directly now, I think it would be nicer to use a seperate function for importing a iCalendar file in total. This is because a PUT with a iCalendar file currently results in the entire calendar being deleted and afterwards the elements from the file are added again. This is because otherwise no elements can be deleted (import only allows for adding). Another disadvantage is that every entry is therefore seen as being modified on a PUT. A better solution would be a seperate function that check for each element if it has changed / added / deleted and modifies these entries accordingly.
Ah, that's nice :)
Currently, I have two ideas for building the webdav/ical support into this. I can add files with the name calendar.ics in the listing of kronolith (so you get something like the following):
calendar_name/
calendar_name.ics
other_calendar/
other_calendar.ics
Or another solution is seperating it into different parts of the tree structure:
kronolith/webdav/calendar_name.ics
kronolith/caldav/calendar_name/
I've also looked a bit more into to CalDAV, but the problem of putting events seems rather simple. First, you have to put it into a existing calendar directory. If you want to put it into a new calender, you first have to create a new calendar with MKCALENDAR (part of the CalDAV spec), and then put it into the folder which is created with the MKCALENDAR command.
For adding calendar's with WebDAV, it should be simply creating a calendar with the (part of) the file name (so calendar_name for calendar_name.ics). After this, the data of the file can be imported (or does the import already create a new calendar if it doesn't exists?).
I think it is still necessary that the Horde WebDAV class uses some registry function for PUT, so it is possible to call the import function with the necessary parameters. I don't see how this could really be solved using the current browse function.
Just another question, how mature is the CalDAV support, or is it in it's current state nothing more that getting events?
I wonder why it worked for me then... Anyway, fixed in CVS.I've found the problem... It was a stupid bug in the api.php from kronolith. On line 225 it said:$modified = _modified($event['uid']);
instead of:
$modified = _modified($event->getUID());
When I changed this, I can download the calendar events, pretty stupid it doesn't give any error message, it simply stops at the function call. I do have error_reporting on E_ALL, so why it doesn't complain about anything, I don't know...
Because I was wrong. Due to the, *cough*, interesting implementation of HTTP_WebDAV_Server, http_GET() is actually echo'ing the output.Well, I can't find it then... HTTP_WebDAV_Server_Horde extends HTTP_WebDAV_Server and in this class the GET method doesn't return anything, which it sould, because rpc.php simply calls Horde_RPC_webdav->getResponse(), which in it's turn uses ServeRequest() on the HTTP_WebDAV_Server... This last method is the default HTTP_WebDAV_Server method, which expects the GET function to return the content of the file.
I also checked with the latest files on cvs.horde.org and they are the same (last change is from six weeks ago). I guess I'm then missing something somewhere.
rpc.php and Horde_RPC_webdav are taking care of that.> Hm, works fine here. Did you try with Horde from HEAD?
I've tested it with the HEAD snapshot from yesterday... I do see file sizes with each event, but I get zero bytes when I download it. I've looked into the code of the webdav server and I see no output being printed or echo'ed in the GET function, which is how de PEAR WebDAV implementation works from what I've seen.
> I saw that GET is already implemented, however, it just gives empty
> files if I download a calendar event.
Hm, works fine here. Did you try with Horde from HEAD?
> On the second issue: iCal over WebDAV works very simple, with a GET
> you retrieve a single iCal file which represents the entire calendar.
> With a PUT you upload the same sort of file. There is no really
> advanced handling of single events e.d. That is the reason I would
> then like to change the behaviour of the kronolith webdav browser, so
> it only gives you these single files for each calendar instead of a
> directory with events beneath it.
Ah, I didn't know that. I only worked with GroupDAV/CalDAV so far and didn't notice that WebDAV calendar clients only work with a single iCal file. It makes sense then to keep two separate entry points, just like they are now and only try to share as much code as possible.
> Because of this change, it would also be necessary to change the GET
> and PUT function for kronolith, because those function should then
> export en import the iCal data. That's the reason behind the idea of
> using different function for this trough the registry...
As import() already deals with single as well as multiple events in one iCal file, we should be able to use only one PUT implementation for both scenarios. GET is already implemented in ics.php anyway.
Maybe it is a better idea to keep my current patch pretty much as is, and use the current WebDAV implementation as a basis for CalDAV support, where a calendar is a collection and events are single resources. This would make it possible to use both clients that only support iCal over WebDAV and not (yet) CalDAV.I saw that GET is already implemented, however, it just gives empty files if I download a calendar event.
On the second issue: iCal over WebDAV works very simple, with a GET you retrieve a single iCal file which represents the entire calendar. With a PUT you upload the same sort of file. There is no really advanced handling of single events e.d. That is the reason I would then like to change the behaviour of the kronolith webdav browser, so it only gives you these single files for each calendar instead of a directory with events beneath it.
Because of this change, it would also be necessary to change the GET and PUT function for kronolith, because those function should then export en import the iCal data. That's the reason behind the idea of using different function for this trough the registry...
Regarding PUT/GET: GET is already implemented and works fine. Go with any webdav browser (cadaver, konqueror, etc) to /horde/rpc.php.
PUT is missing yet, mostly because the reasons I mentioned (having to map PUTted file names to object IDs in Horde). If is going to be added, it should use the APIs' import() methods.
Regarding directories: why do you want to have a flat webdav directory structure? How do you want to specify which calender PUTted events should go to?
Hmm, some things might not be very clear form my last comment :)
What I mean is that it might be a good idea to change the PUT and GET functions in HTTP_WebDAV_Server_Horde, so it is possible to also call a function through the registry.
This way, it's possible to implement the PUT and GET functionality for the iCal calendars.
> 1) Great!
I just want to echo this. I'm really looking forward to seeing this get into CVS.
> Just take a look at how webdav browsing works in HEAD currently. It shows
> you the calendars and events depending on the permissions you have,
> exactly like the regular UI, or the API (which is actually used to build the
> listings).
I wonder whether it would be possible to simply change this behaviour... Meaning that beneath the kronolith directory through webdav there are only iCal files instead of directories with events. This means only changing the _kronolith_browse function in the api.
Using the registry to also call specific methods in the Kronolith api when GET and PUT are used, much in the same way as PROPFIND now (using the browse function). Changing my patch to do this would probably be not very hard, i've allready written the api functions there.
This entire idea is ofcourse not very useful if the webdav implementation in it's current state is already used for other purposes, but I think most people would like this new behaviour. It also is very integrated in the current structure :)
> I'm wondering whether it would be possible to also model this in the
> generic webdav access. Essentialy it is nothing more that a list of
That should be the final goal.
> file that are icalendar files. Problem only is that which files will
> be there should be dependant on the authentification, don't think it
> would be really nice to be able to see other people's calendars,
> albeit only the file/calendar name. I also don't know what the policy
> is here, so whether this is even wanted or that a seperate interface
> file is a better solution.
Just take a look at how webdav browsing works in HEAD currently. It shows you the calendars and events depending on the permissions you have, exactly like the regular UI, or the API (which is actually used to build the listings).
> Currenty nothing really happens ;) This patch is really something to
> get it to work, I was really getting frustrated with the fact that
> these solutions where not really available. I've tried Open-Xchange,
> but here the calendar didn't let me delete events over iCal/WebDAV
> and their webmail interface is really crap.
This might be much easier if using CalDAV or GroupDAV which is supported by at least KDE's and Gnome's calendar clients, unfortunately not yet by Sunbird.
> Great, patches are welcome. The webdav support is still incomplete, so
> any help to finalize this would be awesome. Please note that whatever you
> change must not break "regular" webdav access through /horde/rpc.php.
I'm wondering whether it would be possible to also model this in the generic webdav access. Essentialy it is nothing more that a list of file that are icalendar files. Problem only is that which files will be there should be dependant on the authentification, don't think it would be really nice to be able to see other people's calendars, albeit only the file/calendar name. I also don't know what the policy is here, so whether this is even wanted or that a seperate interface file is a better solution.
> I'm also curious how you solve the problem that clients provide there own
> "file names" when PUTting data to the webdav server that we can't use
> internally in Kronolith. But I'll probably find out if I actually look at your code. ;)
Currenty nothing really happens ;) This patch is really something to get it to work, I was really getting frustrated with the fact that these solutions where not really available. I've tried Open-Xchange, but here the calendar didn't let me delete events over iCal/WebDAV and their webmail interface is really crap.
I then saw the ics.php file in the latest cvs and saw how easy it wat, so I made this thing quickly so I can use it for my personal use and the study association where I'm a member of. The main reason I committed it, is because I saw more people having the same problem, I also noticed similar requests on the Horde mailing lists.
> Hmm, I've looked into this and I see how PROPFIND could be handled
> better :). I'll try to create a new version somewhere in the next
Great, patches are welcome. The webdav support is still incomplete, so any help to finalize this would be awesome. Please note that whatever you change must not break "regular" webdav access through /horde/rpc.php.
I'm also curious how you solve the problem that clients provide there own "file names" when PUTting data to the webdav server that we can't use internally in Kronolith. But I'll probably find out if I actually look at your code. ;)
>My fault, I thought I only added the webdav driver in 3.1. But it still doesn't make
> sense to make this work with Horde 3.0, because the 3.1 driver already
> implements PROPFIND for example. So you should rely on Horde 3.1, reuse
> what's there, detect it, and simply send an HTTP error to the client if you
> recognized an older version.
Hmm, I've looked into this and I see how PROPFIND could be handled better :). I'll try to create a new version somewhere in the next week or two, I'm really busy so I hope I have some time for it. I'll also make it dependant on Horde 3.1 and use ics.php as the filename for the interface.
> If you mean that I should have named webdav.php ics.php, I didn't do
> that because I didn't want to overwrite existing code. If this is
> committed into CVS, I also don't see the use of the ics.php anymore,
> because the WebDAV module can do exactly the same and more...
Exactly, that's what I was talking about. There is no need to keep the current ics.php if webdav.php provides the same features, but we also don't want another script.
> 3) You should already check there if RPC/webdav.php exists at all for
> BC reasons, because it has only been added in Horde 3.1.
>
> I don't really understand what you mean, I've written this patch
> using the latest CVS from Kronolith, but with the existing stable
> Horde 3.0.6/3.0.7. This RPC / webdav is already present there,
> however, I haven't seen any component yet that uses it.
My fault, I thought I only added the webdav driver in 3.1. But it still doesn't make sense to make this work with Horde 3.0, because the 3.1 driver already implements PROPFIND for example. So you should rely on Horde 3.1, reuse what's there, detect it, and simply send an HTTP error to the client if you recognized an older version.
2) You should reuse the already existing ics.php.
I don't see how this is possible... Currently this file does nothing more that download the calendar in the iCal format, the only possible solution would be to implement the webdav object in this file, but that's not really a good solution.
Also in ics.php there is exactly the same code as in the api.php. I choose to only include the code from api.php to minimize redundancy of the code.
If you mean that I should have named webdav.php ics.php, I didn't do that because I didn't want to overwrite existing code. If this is committed into CVS, I also don't see the use of the ics.php anymore, because the WebDAV module can do exactly the same and more...
3) You should already check there if RPC/webdav.php exists at all for BC reasons, because it has only been added in Horde 3.1.
I don't really understand what you mean, I've written this patch using the latest CVS from Kronolith, but with the existing stable Horde 3.0.6/3.0.7. This RPC / webdav is already present there, however, I haven't seen any component yet that uses it.
State ⇒ Feedback
I wasn't able to take an in-depth look yet, but I have a few comments already:1) Great!
2) You should reuse the already existing ics.php.
2) You should include files where you need them, i.e. not in webdav.php/ics.php, BUT
3) You should already check there if RPC/webdav.php exists at all for BC reasons, because it has only been added in Horde 3.1.
Just tested it in SunBird and everything seems to be working great. Migrated my own calendar from www.icalx.com to my own server running kronolith and it worked without any trouble.
It would like to see that extra calenders could be given a name a bit nicer then display_cal=38a74970ff911afbc6bdada650df1d29 or something like that. But that is probably more a kronolith issue.
I forgot to add some usage data :)
- You have to make sure Kronolith is working properly (first adding / deleting e.d. should work through the web interface)
- Make sure Pear's HTTP_WebDAV_Server is installed. The latest version has a bug which gives a parsing error on line 132, there is a trailing " there that should be removed.
- The url to use is the following: (http/https)::/example.com/horde/kronolith/webdav.php/
Mark the trailing / after webdav.php. This is necessary if you use the latest version of HTTP_WebDAV_Server (how annoying). With version 0.99.1 it works also without the trailing /
- If you wish to access a other calendar than the default (with the same name as your username), you can give this as a parameter:
(http/https)::/example.com/horde/kronolith/webdav.php/calendar_name
New Attachment: webdav_ical.patch
Queue ⇒ Kronolith
Type ⇒ Enhancement
Priority ⇒ 1. Low
Summary ⇒ WebDAV / iCal plugin voor kronolith
State ⇒ New
This patch adds support for using a Kronolith calendar over WebDAV. It simply combines the existing features such as import/export of iCalendar files and the Horde WebDAV server.
Currently it only supports GET and PUT, I've tried to create a simple PROPFIND but wasn't yet succesfull. It is however already usable in it's current state. I'm using it for my own calendar in combination with Sunbird on different Horde installations.