Reply:



Ping.



Havn't been engaged in Horde for years now. After I submittet this, I heared

that the focus for Kronolith is acting as WebDAV server instead. I guess

that work is done by now...



   //regards: Johan Ekblad

Ping?

Are you going to update the patch?

Flagging this as a Krono 3.0 item.

If you extend a class, there is no need to implement all the methods 
again, only to call the parent class' methods. Only implement those 
methods that really need to do something different than the parent 
class. The same is true for properties.
What happens if the object has been changed on the webdav server after 
the user changed the event but before it is saved? Is there the any 
way to make sure such conflicts don't happen?
That would be a good idea, at some point.
I'm not sure. Did you take a look at how often/when we update iCal 
remote calendars currently?



Some general notes:

- Your expected webdav folder structure looks pretty strict, is it 
possible to make this more flexible? Which webdav server did you use, 
i.e. which is providing this structure?

- Please take another look at the coding standards. Your indenting is 
pretty off, as are some curly braces in if-clauses.

This is not necessary, load the parent class in the top of webdav.php instead.
If the global Identity object doesn't exist yet at this point, 
instantiate it. Scan for Identity::singleton in the sources for 
examples.

OK. Actually I tried to make a search first, but apparently not good 
enough... and at the mailing list you wrote "That makes sense, but it 
should be optional. If you are going to do

that, you should extend Kronolith_Driver_sql with your new driver." 01/30/2006



But the functionality is somewhat different. In my implementation the 
calendars are "always in sync" but as I understand the other 
implementation (ticket 3032), the way you keep the calendars in sync 
is manually via the import/export function.



Whould it help somewhat if I rewrote the code so it uses the same 
GET/PUT methods as ticket 3032 does, instead of HTTP_WebDAV_Client, as 
I'm using. Maybe we have to skip locking of a WebDAV resource then...

Great, but how about asking on the mailing list or searching this 
tracker first? Now we have two implementations (ticket 3032) and a lot 
of duplicate work.

webdav.php (last attachment) extends sql.php. All database operations 
are done in sql.php.

The function listEvents first calls saveUpdatesFromWebDAV, which 
updates the local database with those UID:s that exists at the webdav 
server but not in database. If the same UID:s exist on both places and 
"some" of the attributes differ, the local database is updated.



All operations that change the data in the local database are executed 
in the following order:

1) call saveUpdatesFromWebDAV to recieve a fresh update from webdav

2) do the local database operation (update, new, change, delete, etc)

3) call saveUpdateToWebDAV to save the update back to the webdav server



Note1: I have prepared, so that it should be easy to lock the webdav 
resource in 1) and release the lock in 3) to aviod inconsistent 
updates at the webdav server, but it's not done yet.



Note2: The saveUpdatesFromWebdav maybe doesn't have to be updated each 
time the calendar is listed. Maybe a refresh-button somewhere?

Some more source code (will be one more file uploaded). I also had to 
change in Driver.php, so that the sql driver gets loaded before webdav 
driver. (Since it's a subclass). I also made an default-argument for 
the toiCalendar-function (couldn't get hold of the identity when 
called from  saveUpdateToWebDAV in webdav.php)

A new driver "webdav" with the same sql-settings as the sql driver + a 
few extra parameters:

depdriver - a dependent driver that has to be loaded before the webdav 
driver (since its a subclass of sql.php) ("sql" by default)

webdavurl - webdav directory on the server where the users calendars 
are stored/retrieved

webdavext - the extension on the users calendars ("ics" by default)