HOME

5h-3LL 1.0

DIR: /srv/http/vyvoj.adent.cz/egroupware/pfi/icalsrv/doc
/srv/http/vyvoj.adent.cz/egroupware/pfi/icalsrv/doc/

Current File : /srv/http/vyvoj.adent.cz/egroupware/pfi/icalsrv/doc/IcalSrv-protocoldiscussion.dox

/*! @page pagewebcaldiscussion Discussion on iCalendar based protocols for Egroupware
@todo check text and spell errors
@version 0.0.03
@author JVL

In the egroupware mailinglists there has been some discussion about
what features you would like to see in a calendar protocol to access
the data in Egroupware. Below I will put a small digest of this
discussion.

@section secicalforegw iCalendar based protocols and Egroupware

(a piece of a egroupware posting on 20060127...)

So lets speak a bit on your question about "deleting events": I was
waiting for it to come :) So I guess 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:

<ol>
<li>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..)

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

<li>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 :) )

</ol>

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 1) and just do deletions on the server.... or via xmlrpc..

I hope this clarifies a bit.

So as a resumee:

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

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

<li>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.
</ul>

success

Jan

......

@section secxdelete Post scriptum 1: the X-DELETE feature

As is also mentioned in the mainpage, I introduced in the meanwhile
the sneaky feature of event/todo deletion by filling the summary field
with the title: <code> X-DELETE </code> (or as an alternative:
<code>_DELETED_</code>.

This you can use to propagate deletions from the client to the
browser. Someone (L. Tullipan if I remember correctly) already
proposed that this feature could be used, by e.g. a sunbird plugin, to
make an easy alternative way to do deletions via a client.

@section secvirtcals Post scriptum 2: Virtual Calendars since v 0.9.30

Since version 0.9.30 Icalsrvsupports a first set of so called
virtual calendars. These virtual calendars are definitions of
the resource (e.g. the Egroupware Calendar of person X or the
Egroupware Infologs of person Y) and the periods for which calendar
data from Egroupware are to be exported. In each virtual calendar you
can define these settings and then you can access a certain virtual
calendar (by its URL) from the client.

In this way you have a certain control of what data you will receive
in your client, when loading a calendar from Egroupware via IcalSrv.