Sun, 05 Apr 2026 15:59:04 +0000 https://bugs.horde.org/ticket/3472 Kronolith acting as WebDav client 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) Tue, 14 Feb 2006 00:20:53 +0000 https://bugs.horde.org/ticket/3472#t16720 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) Tue, 14 Feb 2006 00:37:44 +0000 https://bugs.horde.org/ticket/3472#t16721 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? Tue, 14 Feb 2006 00:53:30 +0000 https://bugs.horde.org/ticket/3472#t16723 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. Tue, 14 Feb 2006 08:20:20 +0000 https://bugs.horde.org/ticket/3472#t16727 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... Tue, 14 Feb 2006 09:26:35 +0000 https://bugs.horde.org/ticket/3472#t16729 > 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. Tue, 16 May 2006 16:32:28 +0000 https://bugs.horde.org/ticket/3472#t20249 > 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. Tue, 16 May 2006 16:41:52 +0000 https://bugs.horde.org/ticket/3472#t20250 Flagging this as a Krono 3.0 item. Fri, 17 Nov 2006 22:33:35 +0000 https://bugs.horde.org/ticket/3472#t26306 Are you going to update the patch? Fri, 13 Apr 2007 15:11:23 +0000 https://bugs.horde.org/ticket/3472#t31551 Ping? Thu, 10 May 2007 09:23:41 +0000 https://bugs.horde.org/ticket/3472#t32880 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 Thu, 10 May 2007 10:28:48 +0000 https://bugs.horde.org/ticket/3472#t32899