there are open tickets for the other share apps with webdav support

Yes, if this has been consistently applied to all share-apps in the meantime.

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 #28 and #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

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

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.

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.

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).

Makes sense.

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.

That's my favourite solution too.
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.
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.

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.

Hm, works fine here. Did you try with Horde from HEAD?
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.
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.

I just want to echo this. I'm really looking forward to seeing this 
get into CVS.

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 :)

That should be the final goal.
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).
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.

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.
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.

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. ;)

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.

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.
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.

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

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.