[Kolab-devel] Strange behavior with ICal snychronisationKolab 2.2.3
Gunnar Wrobel
wrobel at pardus.de
Wed Mar 24 12:58:30 CET 2010
Quoting ComCept Soliva <soliva at comcept.ch>:
> Hi Gunnar
>
> Many thanks for your feedback (by the way I wrote Bernhard a sperate mail
> with a issue you would be probably intressted but is nothing to be posted
> :-)
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Mittwoch, 24. März 2010 11:03
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Strange behavior with ICal snychronisationKolab
> 2.2.3
>
> Hi Andrea,
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi all
>>
>> Following feedback from a test which I did with a MAC and ICal
> functionality
>> using Kolab 2.2.3. I configured a ICal Kalender with the name of the user
>> account and with the URL:
>>
>> https://[host}/client/rpc.php/kronolith/[Kolab User ID]
>>
>> After the configuration I announced the configured Calender within ICal to
>> the Kolab server and each entry of the calender was "put" to the related
>> account on the Kolab server. After successful "announcement" we checked
> over
>> Horde if all events was put correct to the users account and we can
> confirm
>> this. In the first view everything was looking perfect. After more tests
> we
>> noticed following:
>>
>> - Within every announcement or/and actualization of the related Calender
>> within ICal the request is deleting EVERY Calender entry and "put's" every
>> entry again to the Kolab server (no synch only a "delete all" as
> afterwards
>> a "put again all"). Why is the stuff not synched and instead every time
>> deleted and from scratch "put" again to the server?
>
>>> I do not think you can do more with WebDAV. "PUT" is restricted to
>>> uploading a complete file to the server.
>
>>> I checked the code and it also does not support more than this.
>
>>> Another indication that the behavior you describe is to be expected
>>> might be that your client apparently knows this also. Otherwise it
>>> would try to update single events, no?
>
> That is a good question and has probably something to do that Apple removed
> the WebDav config position within ICal?!
>
>>
>> - Another issue we recognized is, if the users launches within ICal the
>> announcement and if you have more as - lets say 50 entry - ICal will give
>> back an Error telling that the announcement was not successfull but in the
>> background all data is "put" correctly (except that everything is again
>> first of all "deleted" and afterwards from scratch again "put" to the
> Kolab
>> server). It seems that ICal goes in a timeout and and Kolab works straight
>> ahead in the background?
>
>>> Do you see any associated errors on the server? Or is this purely a
>>> client issue? Does the client tell you more about the reason why it
>>> fails?
>
> As a pity no the client only tells "it was not possible to announce the
> data/calender" nothing else?! The server itself shows absolut no errors.
>
>>
>> - I looked to the flat files on the Kolab Server and the format I see
> there
>> is similar to a Mail entry (Imap entry) meaning the stuff is in kolab.xml
>> format and everything seems to be fine as it must be.
>>
>> - Is this something which is supported or did I try something which is not
>> visible on was not planed?
>>
>> The main issue here is really that everytime a calender entry changes or
>> whatever that the process will delete EVERYTHING within the Calender on
> the
>> Kolab server and put afterwards again EVERYTHING on the server. From
>> performance etc. reasons this is ugly and not really that what should be
>> or.....?
>
>>> This will only change with support for better protocols such as CalDAV
>>> or GroupDAV. At least as far as I know. Currently only WebDAV is
>>> supported.
>
> Understood....the question would be in this case "Because I do not have
> anymore the WebDAV config position in ICal "only the position private
> server" how can ICal be configured to use WebDAV?
>
>>
>> - Within Snow Leopard 10.6 -if I'm correctly informed - Apple remove the
>> WebDAV functionality within ICal (they want that .MAC is used to earn $).
> I
>> know there is a hack to be again able to use WebDAV but if I'm correct
> Kolab
>> does not support WebDAV in this way that the stuff is afterwards available
>> within Horde etc. correct?
>
>>> I would say it does. But I might misunderstand your question.
>
> As mentioned above I only have two position to configure which means:
>
> .Mac mobile
> Private Server
>
> I used Private Server and used the link:
>
> https://[host}/client/rpc.php/kronolith/[Kolab User ID]
>
> username and password
>
> More I can not configure which means if this is done every event is going to
> the server and on the server every event is stored in kolab.xml format
> within IMAP. Again that we have no misunderstanding if so done the stuff is
> in a perfect way afterwards available within kronolith. The only issue is
> that if a event or whatever is changed the stuff is on the server from the
> client overall deleted and again send to the server (this is a bad think and
> is pointed to Bernhard within a separate mail).
>
> If I understood you correct you have the opinion that ICal within Snow
> Leopard can be configured with WebDAV function (even it is limited) that can
> be the question is only how is this done if I do not have anymore the WebDav
> function within ICal Snow Leopard?
Hm, no not really. First of all I don't know anything about ICal on
Snow Leopard. I might ask my wife if I dare touch her Mac Book and
play around with ICal. But I assume she'd rather divorce than let a
programmer misconfigure her precious toy :)
So I used Thunderbird/Lightning to test the WebDAV functionality today.
And I think that this is working fine for you from what you describe.
I think this is the intended mode of operation when using WebDAV. I
assume the intended
mode of synchronization is GET -> make local changes -> PUT (or better
LOCK -> GET -> make local changes -> PUT -> UNLOCK)
Cheers,
Gunnar
>
> Kind regards
>
> Andrea
>
>>
>> Sorry many questions but at the moment I'm a little bit confiused and not
>> understanding the behavior specially because from scratch it would work if
>> this case with DELETE all first and afterwards put again all on the server
>> wouldn't be. Can you please give me quick a feedback if I did something
>> false or did understand something false? Wihtin the logs I did not noticed
>> something special.
>>
>> Kind regards
>>
>> Andrea Soliva
>>
>> Mail: soliva at comcept.ch
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>
>
>
> --
> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> E-mail : p at rdus.de Dr. Gunnar Wrobel
> Tel. : +49 700 6245 0000 Bundesstrasse 29
> Fax : +49 721 1513 52322 D-20146 Hamburg
> --------------------------------------------------------------------
> >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
--
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
--------------------------------------------------------------------
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100324/00d510a8/attachment.sig>
More information about the devel
mailing list