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:
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..)
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
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 1) and just do deletions on the server.... or via xmlrpc..
I hope this clarifies a bit.
So as a resumee:
success
Jan
......
X-DELETE
(or as an alternative: _DELETED_
.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.
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.