[#3472] Kronolith acting as WebDav client
Summary Kronolith acting as WebDav client
Queue Kronolith
Queue Version HEAD
Type Enhancement
State Rejected
Priority 1. Low
Owners
Requester jka@eminds.se
Created 2006-02-14 (5265 days ago)
Due
Updated 2007-05-10 (4815 days ago)
Assigned
Resolved 2007-05-10 (4815 days ago)
Milestone Kronolith 3.0
Patch No

Comments
jka@eminds.se 2006-02-14 00:20:53
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)

jka@eminds.se 2006-02-14 00:37:44
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)

jka@eminds.se 2006-02-14 00:53:30
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?



Jan Schneider <jan@horde.org> 2006-02-14 08:20:20
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.

jka@eminds.se 2006-02-14 09:26:35
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...



Jan Schneider <jan@horde.org> 2006-05-16 16:32:28
> 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



This is not necessary, load the parent class in the top of webdav.php instead.



> default-argument for the toiCalendar-function (couldn't get hold of

> the identity when called from  saveUpdateToWebDAV in webdav.php)



If the global Identity object doesn't exist yet at this point, 
instantiate it. Scan for Identity::singleton in the sources for 
examples.

Jan Schneider <jan@horde.org> 2006-05-16 16:41:52
> webdav.php (last attachment) extends sql.php. All database operations

> are done in sql.php.



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.



> 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



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?



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



That would be a good idea, at some point.



> Note2: The saveUpdatesFromWebdav maybe doesn't have to be updated

> each time the calendar is listed. Maybe a refresh-button somewhere?



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.



Chuck Hagenbuch <chuck@horde.org> 2006-11-17 22:33:35
Flagging this as a Krono 3.0 item.

Chuck Hagenbuch <chuck@horde.org> 2007-04-13 15:11:23
Are you going to update the patch?

Jan Schneider <jan@horde.org> 2007-05-10 09:23:41
Ping?

Jan Schneider <jan@horde.org> 2007-05-10 10:28:48
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