Hi,
nice to hear of experimenters with the ical server code.
(I guess that you are using the newer version as mentioned in this post
http://www.egroupware.org/forum/index.php?t=msg&th=4922&start=0&S=5ef0d6888069ff77f84b079d9d172cc0
because this also provides for vtodo’s import and export. Soon a newer
improved version will come and it will be integrated in the cvs for newer
versions etc…)
But for your question about “deleting events”: I was waiting for it to come
So I should clarify my opinion a bit on that… So that in future I can
refer to it (should make it to the wiki I guess…)
This issue is this: with the “ical upload/download over http” you can
basically only upload or download a COMPLETE calendar file, not a part of it
or a single event. And there is also no provision for “deleting” a part of
a calendar on the server.
Other “real” calendaring protocols like groupdav or caldav (the 2 most
serious OS candidates at this moment) -in contrast - do provide such
features.
Nevertheless knowing that, this leaves you with (at least) 3 ways to
simulate deletion of events on the server and client:
variant 1) you disable deletion (simulation) on both the client and the
server.
This means: on the server you append everthing that is uploaded onto the
stuff already there. Either with or without overwriting “related” already
existing events enabled.
And on the client you do the same with the downloaded stuff.
You could see this as a --simple-- form of syncing the client and server.
But with disadvantages: you need to have an extra method both on the server
and client to limit your up/download calendar period. Otherwise at some
moment you will be sending the acumulated events of 10 year each time a new
one is set!
Unfortunately the calendar sent does itself have no fields to hold this
period (it is about) so you must communicate this period of coverage with
external means.
Using the e.g. sunbird and egw in this way seems quite feasible. Note that
in sunbird you could simulate your “limited coverage period” by using the
remote (egw) calendar only for the active period and holding the other stuff
in you local calendars. In eGW you should have some method of setting your
"limited-period-coverage for import/export" from withing you user calendar
profile or so. (we will be working on that…)
variant 2. you allow “simulated” deletion by somehow just throwing away
differences between the uploaded and already present data on the server.
If you think about it you will see that this is complicated!
E.g. how do you determin if a difference is a result of a deleted event on
the client or a added event on server (after the previous sync action) etc.
All this is amply discussed and solved in synchronisation protocols such as
syncml and the opensycnc/multisync. In essence: doing “deletion” of
something without a reference to that something is unwise, unless you have
full fledged synchronisation system (with anchors, version stamps and
whatever…)
So my message is simple: use these protocols when you want to do real
syncing.
But you may ask: when I use phpicalendar or apple’s Ical I can do deletes?
Oke thats variant 3
variant 3) you always let the uploaded or downloaded data replace your
existing data (possibly combined again with a "limited-coverage-period"
principle).
Well this may work if you have a good locking mechanisme (prevent writes by
other clients while client x is changing) combined with a disciplined
’download-latest-version-and-lock’ before change and update. Something which
may be do-able with few disciplined "change-'allowed users, that coordinate
their calendar update activities. But not in a general (massive) groupware
deployment setting.
If you wanted implement some locking over the http and maybe add some
provisions to mark “seen/changed” events etc. you find yourself redoing
webdav for this and thus soon find yourself ended up in
reinventing/implementing caldav/groupdav…
(Yes I would like to have that in egw indeed )
So my advice is still: use the simple upload/download over http of ical just
for read, add and overwrite. For deletion use any of the other access
methods to the server (that all work by on the basis of an explicit
reference to the item to be deleted).
And if you want to do real synchronisation for example with the ical file of
your calendar I suppose using multisync between your ical file and the
syncml interface of egw should in principle work best. I have not tried it
though.
On the other hand if you want to keep it simple you can also use my variant
- and just do deletions on the server… or via xmlrpc…
I hope this clarifies a bit.
So as a resumee:
-ical server is quite nice to use in he variant 1 setting. (with deletions
by some other method) Especially with my new variant that is coming to cvs
soon…
-ical over http without tagging and locking (webdav) is not suited for
synchronisation. If you try to incorporate these your are building
CALDAV/GROUPDAV. But unfortunately we don’t have that yet.
- if you want to do real syncing at this moment, without using any of the
specific egw client protocols (xmlrpc+egwosync, xmlrpc+kontact, soap+…,)
as best option I see using syncml (the name says it…) plus a syncml client.
And if you don’t have a syncml client use multisync as a mediator (good
towards ical files, evolution, …) between your client and egw with syncml.
success
Jan
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
