Menu

#2304 Sync Thunderbird + Lightning 0.8 don't work fine

open
5
2013-01-14
2008-04-10
No

I'm using Thunderbird 2.0.0.12 and Lightning 0.8 with webcalendar 1.1.6.

When I create new events in Thunderbird, these events appear normally on the webcalendar(web interface).

When I delete a event created in Thunderbird, these event are not deleted on the webcalendar(web interface).
Only if using the web interface the event is really deleted on both (thunderbird and webcalendar).

We need the event removed by Thunderbird, also to be removed in Webcalendar.

How can I resolve this problem?

Discussion

  • Steffen Voß

    Steffen Voß - 2008-04-14

    Logged In: YES
    user_id=749269
    Originator: NO

    The code suggests to not delete but cancle events.

     
  • Koppany Palinkas

    Options on Thunderbird

     
  • Koppany Palinkas

    Logged In: YES
    user_id=2059820
    Originator: YES

    But the "cancel" button don't appear.
    Attached the avaiable options.
    File Added: Sem título.jpg

     
  • Steffen Voß

    Steffen Voß - 2008-04-14

    Logged In: YES
    user_id=749269
    Originator: NO

    Double Click the event, Click Settings or Options (my Lightning is German and it says "Einstellungen") - second but last menue entry on the right. There you can set the Status to cancled

     
  • Koppany Palinkas

    Logged In: YES
    user_id=2059820
    Originator: YES

    If you create an event wrong, and want to delete.
    On thunderbird I delete him, to refresh the page. But in Webcalendar excludes only makes within the page of Webcalendar.

     
  • Marco van Beek

    Marco van Beek - 2008-08-08

    Logged In: YES
    user_id=554611
    Originator: NO

    I have recreated this error as well. The problem would seem to be that the entry in Sunbird (or Lightning) is simply removed from the iCal publish. So how does WebCalendar know to remove this entry. I think the heart of the matter lies in the webcal_import_cal data. As far as I can tell, an entry is not created in here until the calendar is exported to iCal. So that distinguishes a new entry in the web calendar versus one that is simply missing from the remote iCal client. A well behaved iCal client should check for an updated iCal file before publishing (for example see discussions here: https://bugzilla.mozilla.org/show_bug.cgi?id=329570 & https://bugzilla.mozilla.org/show_bug.cgi?id=290446\).

    In the long term, Etag records might work but I think the answer could be as follows:

    When icalclient.php recieves an iCal file via PUT (aka publish), it updates a new timestamp column of each record received, against a record in the matching webcal_import_cal row. If the iCal file is missing an entry, there will be no update of the timestamp for that row. Since the timestamp needs to be identical for all updated records, icalclient.php would create one and explicitly set it for each row that matched.

    icalclient.php could then look for any entries that are older than this time stamp, indicating missing / or deleted records. Since if the record is new and from WebCalendar, it will not yet have an entry in this table, it would not be found, and would not be affected, and exported on the next GET request (aka subscription).

    icalclient.php then looks for the DTSTAMP: datestamp in the iCal file. This appears to be the datestamp of the last subscribe, and doesn't seem to vary in Sunbird from this value, even when a record is edited, although it seems to be a per entry record so I have a difference of a second or two from first to last record.

    So using the best case value (the newest I suspect), applying a dither factor of maybe 5 minutes to allow for the clocks to be unsynchronised, and checking the timestamp in the unmodified records would give us a good idea if the record was simply missing from the iCal client (because the timestamp in webcal_import_cal was newer) or a delete (because the timestamp in webcal_import_cal was older and therefore was downloaded and subsequently deleted).

    According to the RFC (2445):

    "UID" and "DTSTAMP" properties are specified to assist in proper sequencing of multiple free/busy time replies. [...] The "DTSTAMP" property specifies the date/time that iCalendar object was created. [..] This property will assist in the proper sequencing of messages containing iCalendar objects.

    So it seems to me that DTSTAMP is exactly the data we need to determine which record is newer.

    I will have a play with some code over the weekend. If anything comes of it I will submit the code.

    Regards,

    Marco

     
  • albe

    albe - 2009-03-18

    Marco,
    did you manage to do something about that?
    Did you submit any code in the CVS version?

     

Log in to post a comment.