Rewrite and extension for egw 1.2.
* $Id$
* (see: @url http://www.egroupware.org )
@@ -26,6 +26,7 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*
+ * @since 0.9.06 collect all (todos via query filter iso just 15)
* @since 0.9.00 use of the new egwical class for iCalendar handling with WURH
* TODO list:
* @todo incorporate this icalsrv.php script in
@@ -188,9 +189,13 @@ if ($_SERVER['REQUEST_METHOD'] == 'PUT') {
// timestamp in server time for boical class
'date_format' => 'server'
);
+
+ $todos = array();
$todos_query = array('col_filter' => array('type' => 'task'),
'filter' => 'none',
- 'order' => 'id_parent'
+ 'order' => 'id_parent',
+ 'start' => 0,
+ 'total' => 1
);
// E2.1: search eGW events based on the $events_query
@@ -213,8 +218,16 @@ if ($_SERVER['REQUEST_METHOD'] == 'PUT') {
}
// E3.1: search eGW todos based on the $todos_query
-
- $todos =& $binf->search($todos_query);
+ // JVL: the auto update of the start parameter doesnot seem to work???
+ // so I do it manually..
+ while( $todos_query['start'] < $todos_query['total']){
+ $more_todos =& $binf->search($todos_query);
+ //error_log('td start:' . $todos_query['start'] . ' todo_pos:' . $todo_pos . 'td total:' . $todos_query['total'] . ' count-ids:' . count($more_todos));
+ if($more_todos === false)
+ break;
+ $todos_query['start'] += count($more_todos);
+ $todos = array_merge($todos,$more_todos);
+ }
if (!$todos){
$logmsg .="\n no eGW todos found to export";
// nevertheless fall through to further ical components export
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-Manual-install-howto.txt b/phpgwapi/doc/icalsrv/IcalSrv-Manual-install-howto.txt
deleted file mode 100644
index 652cbb7b63..0000000000
--- a/phpgwapi/doc/icalsrv/IcalSrv-Manual-install-howto.txt
+++ /dev/null
@@ -1,168 +0,0 @@
-/*! @mainpage Ical Service for Egroupware
-
-@NOTE: this text is not up to date
-@version 0.9.01
-@author jvl
-
-@section secinstall SHORT experimental Install How-To:
-
- - Install the icalsrv package by either checking out the icalsrv module from cvs
- or untarring some tarball icalsrv-vx.y.x.tgz of the package (when available).
-
- - @note: The IcalSrv package depends on the availability of an
- EgwIcal (>= 0.9.x) package. So if you dont have this already, be sure
- to install that too.
-
- - Take care that icalsrv.php is .../egroupware/icalsrv.php (and the
- other files from the icalsrv package also in their appropiate places)
-
-- Append something like the following onto your apache httpd.conf part for
-egroupware (assuming that your standard egroupware root path is e.g in
-/var/www/egroupware and with a http alias 'egroupware' pointing to
-it):
-
-
- Script PUT /var/www/egroupware/icalsrv.php
- AddHandler ical/ics .ics
- Action ical/ics /var/www/egroupware/icalsrv.php
- Order allow,deny
- Allow from all
-
-
-
-- Restart apache (or other webserver) ( /etc/init.d/httpd restart )
-
-- Connect your ical client (e.g: Sunbird)
- with http://your.host.com/egroupware/icalsrv.php
-
-- now you should need to authenticate (with your normal EGW login and password)
- and when done you receive the calendar on doing a "reload remote calendars" or so.
-
-- using the "publish" calendar action you can write the (modified) calendar
- from the sunbird client back to EGW
-
-
-@section secdeletions Deleting Calendars, events or todos
-
-deletion of the whole remote calendar is not supported see the @ref
-webcaldiscusspage webcal protocol discussion.
-
-Individual calendar events or todos cannot be deleted either by just
-deleting them on the client and then hoping that this propagates to
-Egroupware on publish. There are various reasons for why this is not
-implemented.
-
-But, you can though delete items by simply renaming them to
-X-DELETE. I you do so they will get deleted in Egw on
-publishing. When you later dowload ("reload"/"refresh") the remote
-calendar in your client you should notice that the event is gone..
-
-
-@section secicalsrvclients Clients for IcalSrv
-
-This is tested with egw1.2rc6 and clients:
-
- * Korganizer (3.3.2,(read) 3.4.2, 3.5.0 (READ+WRITE))
- * Mozilla calendar (2004040813-cal) (READ+WRITE)
- * Evolution 2.2 (READ)
-
-For further use and experience with these clients see @ref
-pageicalsrvclients IcalSrvClients page.
-
-
-@section secpatches Patches
-
-
-You may need to apply some of the patches found in PATCHES.
-Currently there a two patches to fix a warning and a bug (related to EXDATE
-fields handling) in the horde routines.
-Note these may be already committed in the CVS version.
-
-
-
-@section sectest Extra testing
-
-The package contains "compatibility" classes with which you can replace
-the current infolog/inc/class.vcalinfolog.inc.php resp. calendar/inc/class.boical.inc.php
-files.
-
-When done so, the egw syncml, ical import/export and infolog import/export in egw
-will all use the new code. This way you can discover more bugs and failure in the code :)
-
-But, when not renamed, these programs will use the old code (and thus are not broken or
-improved by the new one..)
-
-
-@section secdocumentation Documentation
-
-There is (somewhere) complete doxygen generated documentation for the
-IcalSrv package. Otherwise you can generate it yourself by using
-doxygen on the source filetree. Maybe you are just reading it now ...
-
-
-@section sectestandebug Testing and Debugging
-
-As IcalSrv is still a young and experimental new service for
-Egroupware, that must mediate between a multitude of clients, each
-with their own peculiarities and various internal applications of Egw,
-it is very likely that a lot of problems, deficiencies and bugs will
-appear.
-
-Thus to get error feedback for it is a healthy thing. You should best
-do this --as with any egw application-- using the sourcforge.net
-buglist and the dedicated egroupware forums or mailinglist (see the
-egroupware wiki for more instructions on this).
-
-What to report? Well you should realize that IcalSrv is --currently--
-on it self just a rather simple http interface script, that relies for
-it connection to the egw backends heavily on the new (re) written
-EgwIcal package. This means that problems with in and export of
-iCalendar data will mostly have their source in that (i.e. EgwIcal)
-package! So in case of errors allways report info on that package and
-when debugging try the debug tools for that package.
-
-@subsection subsecdebugtools Debugging of IcalSrv.
-
-IcalSrv does not generate webpages, so to see any error or debug
-information you there a jsut three other places to look at:
-
-+ If you have a really problematic error, IcalSrv will answer your http
- request with a 403 error and --hopefully-- a short message. In some
- clients (like Korganize) this is reported back via a popup with a
- silly message that "exporting went wrong or access denied" or so, instead of displaying
- this message it got together with the 403 error. Note: Sunbird does
- display the message. Unfortunately at the moment this will be mostly
- "VEVENTS import ERROR" or so..
-
-+ The httpd errorlog file/stream. Most problematic errors are reported
- to this file of the egw server. So this is indeed the best source for
- debug info. But to read it, you need access to the
- server and to this log file. So only egw administrators are likely
- the only ones for who this can be of help.
-
-+ The ical.log files and ical.exportxxxx plus ical.importxxxx
- files. If you did install the icalsrv.php file with the variable
- $logdir set to folder where the httpd is allowed to write, you will
- get a detailed log in file ical.log of all uploads and downloads via
- IcalSrv furhtermore for each of these the associated iCalendar data
- will be logged in ical.exportXXXXXX files with XXXX the utime of the
- action. These files reside on the egw server, mostly in /tmp. So again
- to read them you will need access to this server directory.
- Off course this feature needs to be disabled in a production setting:
- the file growth and the security issues of it demand it.
-
-
-@section secbugandtodo BuG and todo list
-
- -see BUGs and TODOs in @ref pageicalsrvbugandtodopage
-
-
-
-
-have fun
-
-
-JVL
-
-
-*/
\ No newline at end of file
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-Overview.txt b/phpgwapi/doc/icalsrv/IcalSrv-Overview.txt
index 7686212217..93b75a01ac 100644
--- a/phpgwapi/doc/icalsrv/IcalSrv-Overview.txt
+++ b/phpgwapi/doc/icalsrv/IcalSrv-Overview.txt
@@ -1,28 +1,73 @@
-/*! @mainpage Ical Service for Egroupware
+/*! @mainpage Ical Service for Egroupware
@note this is still EXPERIMENTAL, USE AT YOUR OWN RISK! and better not yet in a
production environment.
-@version 0.9.01R1
+@version 0.9.01R2
@author jvl
-@date 2006022
+@date 20060314
+
+@section secabout About IcalSrv
+
+At the moment IcalSrv is a small package that allows a socalled
+ical client like Mozilla Sunbird, Apple iCal or Korganizer to
+access the events and tasks from a persons egroupware calendar and
+infolog application, remotely via a "icalendar over http"
+connection. (see @ref secicalsrvclients)
+
+This means that in the client you can download (aka reload )
+the data from an a socalled subscribed calendar on the
+egroupware server and then read and manipulate it offline. On a
+later moment you can upload (aka publish ) this client
+calendardata again to egroupware. The changes made in your client
+should then propagate to your calendars and infolog maintained on the
+egw server. All this provided you have the appropiate access rights
+for the egroupware server data.
+
+At the moment, the IcalSrv service is just a simple --experimental-- variant
+that is not based on webdav (as most of these services), but that may
+nevertheless can be quite practical. It allows only upload and
+download of complete calendars (with events and todos) and no direct
+deletions of events. (Read more on this below at @ref secdeletions )
+
+We are working on extensions towards real groupdav and caldav behaviour.
+
+
+@note We tried to prevent that accidental misuse of the service can ruin all
+your egroupware data. But, be warned: when you use the service for
+publishing from the client, you can (and want to) change data
+in the egroupware server, and thus you have a potential risk of damaging
+or losing egroupware data!
+
+
+
@section secinstall SHORT experimental Install How-To:
+
+ - Best thing to do before installing, is to have a look at the
+ egroupware wiki page about IcalSrv
+ at @url http://www.egroupware.org/egroupware/wiki/index.php?page=IcalSrv
+ .
+ There you can find the current status of the project and see what
+ the latest available versions are and where to find them. In @ref pageicalsrvreleaselog
+ you find a small release notes document that tells of about the changes in
+ the releases.
- Install the icalsrv package by either checking out the icalsrv stuff from cvs
- or untarring some tarball icalsrv-vx.y.x.tgz of the package (when available).
+ or untarring some tarball icalsrv-vx.y.x.tgz of the package (if available).
At the moment (200602xx) the icalsrv is partly in cvs module egroupware and
partly (the documentation only) in module phpgwapi. So be sure to update at least the first one!
- @note The IcalSrv package depends on the availability of an
- EgwIcal (>= 0.9.x) package. So if you dont have this already, be sure
- to install that too. Likewise this can be installed by untarring an appropiate
- egwical-vx.y.z.tgz tarball or by checking out the egwical module from cvs (HEAD).
+ EgwIcal (>= 0.9.x) package. So if you dont have this already, be sure
+ to install that too. Likewise this can be installed by untarring an appropiate
+ egwical-vx.y.z.tgz tarball or by checking out the egwical module from cvs (HEAD).
- Take care that icalsrv.php is .../egroupware/icalsrv.php
(and the other files from the icalsrv package also in their appropiate places)
-- Append something like the following onto your apache httpd.conf part for
-egroupware (assuming that your standard egroupware root path is e.g in
-/var/www/egroupware and with a http alias egroupware pointing to it):
+- Append something like the following onto your apache httpd.conf part
+ for egroupware (assuming that your standard egroupware root path is
+ e.g in /var/www/egroupware and with a http alias
+ egroupware pointing to it):
Script PUT /var/www/egroupware/icalsrv.php
@@ -45,21 +90,6 @@ egroupware (assuming that your standard egroupware root path is e.g in
from the sunbird client back to EGW
-@section secdeletions Deleting Calendars, events or todos
-
-deletion of the whole remote calendar is not supported see the webcal protocol discussion in
-@ref pagewebcaldiscussion
-
-Individual calendar events or todos cannot be deleted either by just
-deleting them on the client and then hoping that this propagates to
-Egroupware on publish. There are various reasons for why this is not
-implemented.
-
-But, you can though delete items by simply renaming them to
-X-DELETE. I you do so, they will get deleted in Egw on
-publishing. When you later dowload ("reload"/"refresh") the remote
-calendar in your client you should notice that the event is gone..
-
@section secicalsrvclients Clients for IcalSrv
@@ -70,13 +100,24 @@ This is tested with egw1.2rc6 and clients:
- Evolution 2.2 (READ)
- Apple Ical, is reported to be working too. (READ+WRITE)
-For further use and experience with these clients and supported features see @ref
-pageicalsrvclients
-Now with screenshots too!
+ See @ref pageicalsrvclients for further use and experience with these
+ clients and supported features Now with screenshots too!!
+@section secdeletions Deleting Calendars, events or todos
+deletion of the whole remote calendar is not supported see the webcal
+protocol discussion in @ref pagewebcaldiscussion
+Individual calendar events or todos cannot be deleted either by just
+deleting them on the client and then hoping that this propagates to
+Egroupware on publish. There are various reasons for why this is not
+implemented.
+
+But, you can though delete items by simply renaming them to
+X-DELETE. I you do so, they will get deleted in Egw on
+publishing. When you later dowload ("reload"/"refresh") the remote
+calendar in your client you should notice that the event is gone..
@section secdocumentation Documentation
@@ -113,6 +154,8 @@ package! So in case of errors allways report info on that package and
when debugging try the debug tools for that package.
+
+
@subsection subsecdebugtools Debugging of IcalSrv.
IcalSrv does not generate webpages, so to see any error or debug
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-Release-Log.txt b/phpgwapi/doc/icalsrv/IcalSrv-Release-Log.txt
new file mode 100644
index 0000000000..9e04ed1782
--- /dev/null
+++ b/phpgwapi/doc/icalsrv/IcalSrv-Release-Log.txt
@@ -0,0 +1,58 @@
+/*! \page pageicalsrvreleaselog Small IcalSrv Release Log
+
+
+\section secrel0907 Release 0.9.07 Small Bug fix to remove todo export limit of 15
+
+- release date: 20060314
+- file: icalsrv-with-doc-0.9.07.tgz
+- via: homepage and egroupware cvs
+
+\subsection subsecrel0907changes Changes from previous version
+
+- icalsrv.php repaired the export of tasks from infolog: limit to 15 is removed!
+- added this release page.
+- updated documentation @ref secabout a bit
+- updated documentation @ref pageicalsrvclients a bit
+
+\subsection subsecrel0904bf01bugs Found bugs and problems
+
+- problems: still demand for more flexible and configurable export filter settings
+ Note: this will not be handled before the new api releases (>0.9.20).
+
+
+
+
+\section secrel0904bf01 Release 0.9.04-bf01 Small Bug fix for php5 (double definitions removed)
+
+- release date: 20060223
+- file: icalsrv-with-doc-0.9.04-bf01.tgz
+- via: homepage and egroupware cvs
+
+\subsection subsecrel0904bf01changes Changes from previous version
+
+- icalsrv.php removed the double declaration. Now php5 should not complain anymore
+
+\subsection subsecrel0904bf01bugs Found bugs and problems
+
+- JVL & Roger (jasjar)?: the export of tasks from egw to the client is
+ limited to 15 (boinfolog search needs to be iterated)
+
+
+
+
+\section secrel0904 Release 0.9.04 First public beta release of icalsrv
+
+- release date: 20060222
+- file: icalsrv-with-doc-0.9.04.tgz
+- via: homepage and egroupware cvs
+
+\subsection subsecrel0904changes Changes from previous version
+
+- many
+
+\subsection subsecrel0904bugs Found bugs and problems
+
+- Ben Donnachie: the fail_exit() function is double declared (left over
+ fromd debugging)
+
+*/
\ No newline at end of file
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-clients.txt b/phpgwapi/doc/icalsrv/IcalSrv-clients.txt
new file mode 100644
index 0000000000..0d11233755
--- /dev/null
+++ b/phpgwapi/doc/icalsrv/IcalSrv-clients.txt
@@ -0,0 +1,229 @@
+/*! @page pageicalsrvclients IcalSrv clients status and supported features
+@author JVL
+@date 20060314
+@version 0.9.01R2
+@todo edit and update the IcalSrv client information document.
+
+On this page you will find some first reports on the use of Egroupware and IcalSrv
+with specific clients.
+
+@section secsupfeatures A short note on supported features in the clients
+
+Whether some feature, like e.g. importing recurrent events from
+a specific client into Egroupware is supported or not, can in
+principle depend on three things: 1) does the client allow setting
+this, 2) does egroupware provide a method for setting and using this
+and finally 3) is the IcalSrv service capable of converting this
+specific info from the client to egw and possibly vice versa?
+
+@subsection secegwexample A small example of a week view in Egroupware
+
+In Egroupware I filled a week calendar with
+ - E1) a recurring dinner event, every two days,
+ - E2) a meeting appointment on monday morning
+ - E3) a free day on thursday
+
+\image html egwcalweek-small.jpg The egw calendar filled in weekview
+
+And in Egroupware Infolog I added a Task and a subtask
+ - T1 Write a XYZ report and as subtask
+ - T2 write chapter 10 of the report
+
+This shows up in egroupware as in the picture below:
+
+\image html egwinfolog-small.jpg The egw infolog list view with 2 tasks
+
+
+
+
+@section secko35 Client: Korganizer 3.5.0 (or Kontact)
+
+Korganizer is the KDE agenda and todo client. I used the 3.5.0
+version for most of the testing (so it should work well ;-) )
+
+
+@subsection subseckorgsetupcal Korganizer: setting up a "remote icalendar".
+
+
+To access the IcalSrv for Egroupware calendar and tasks, you have to
+add a socalled kresource to the resources. You can do this
+either via a wizzard or by doing an Add(resource) in the
+left-under pane.
+
+The resource must be of the type remote iCalendar and for
+reading and writing the same URL should be used.
+When done so, both events and tasks will get imported and exported
+from Korganizer via the same kresource.
+
+
+@subsection subseckorgauth Korganizer: handling Authentication
+
+To authenticate to the IcalSrv from within korganizer.
+you can just set the Download From and Upload To
+fields of the created kresource to one and the same URL as something like:
+http://myserver.myorg.org/egroupware/icalsrv.php
+
+Later on, when you do a reload or a save, a popup window will appear
+that ask you for authentication info. Fill this in and set "remember
+info on local computer" or so and your done.
+
+
+@subsection subseckorgrelopubl Korganizer: Reloading and Publishing
+
+Can be configured as automatic, time triggered or manual.
+
+.....TBW.......
+
+
+
+@subsection seckorgexample Korganizer: week view of the example.
+
+Korganizer connected via IcalSrv to our example account in Egroupware show us the view below:
+
+\image html korganizerweek-small.jpg Korganizer weekview via the remote icalsrv connected to egroupware.
+
+Notice that:
+
+- the Todos are neatly shown in their hierarchy and with their percentages completed
+- the due date of the Todo is shown in the All Day screen
+- the whole day event on thursday is correctly shown in the All Day screen.
+
+
+@subsection seckorgproblems Korganizer: problems
+
+- Korganizer can get its caches confused.
+- Korganizer in default setting does a automatic publish immediately after
+ each change of an event or todo. This can be costly.
+
+....TBW...
+
+
+
+@section secsunbird Client: Sunbird
+
+Sunbird is the standalone calendar application from the Mozilla project.
+
+.....TBW....
+
+@subsection subsecsunbirdsetupcal Sunbird: setting up a calendar.
+
+......
+
+@subsection subsecsunbirdauth Sunbird: handling Authentication
+
+....TBW........
+
+
+@subsection subsecsunbirdrelopubl Sunbird: Reloading and Publishing
+
+............
+
+
+@subsection secksunbirdexample Sunbird: Week view of the example.
+
+On connecting Sunbird to our egw account via icalsrv, this gives us
+the view below:
+
+\image html sunbirdweek-small.jpg Sunbird weekview via the remote icalsrv connected to egroupware.
+
+ Notice that:
+
+- the task hierarchy display (task and subtasks) and the percent
+ complete is not shown in Sunbird. Merely a list of the induvidual
+ tasks. It can though be completely configured to have these and other
+ fields of the tasks shown in the task overview pane.
+
+- the all day event on thursday is present, but due to some bug, it is a bit
+ small displayed..
+
+@subsection secsunbirdproblems Sunbird: problems
+
+- In version 0.2+ under Linux I could not publish recurrent events! It seemed that these
+ also were not exported correctly to a localfile. Seems like a sunbird bug.
+
+- In version 0.2+ under Linux I could not add new tasks in a subcribed calendar.
+ Dont know what is wrong here..
+
+- ..... TBW....
+
+@section secevolution Evolution 2.x
+
+Evolution provides in its 2.x versions utilities to handle calendars
+and tasks. For some strange reason it seems that in the versions that
+I tried (v2. ??) only reading from remote iCalendars is implemented!
+
+For implementing writing via iCalendar there even seems to be a
+pending bounty available... (status: end 2005) Strange if you know
+that evo does have a more or less working caldav-plugin..
+
+@subsection subsecevosetupcal Evolution: setting up a "On The Web Calendar".
+
+Both Calendars and Tasks can be read using, what Evolution calls the
+webcal protocol.
+To setup a remote calendar do the following:
+
+ - in calendar pane, on the right mouse button menu select New Calendar
+ - chose a Type: On the web and give a name etc.
+ This should now build a new calendar in entry in the calendar pane,
+ under the "On The Web" folder.
+ - with the right mouse select its menu and select properties.
+ In here you can set the name, color, URL and refresh timings.
+
+
+@subsection subsecevoauth Evolution: handling Authentication.
+
+You can authenticate to the IcalSrv from within evolution by setting
+in the properties field of a (remote) calendar the URL as something like:
+webcal://username:passwd@myserver.myorg.org/egroupware/icalsrv.php
+
+I didnot find any other method.
+
+@subsection subsecevosetuptasks Evolution: setting up remote tasks
+
+Setting up task access via IcalSrv is quite analoguous to the "On the
+web" calendar setup:
+
+Go to the Tasks pane, select new tasklist, select "On the Web".
+Then via the properties menu of the new "on The Web"-tasklist set the
+correct URL again.
+
+
+@subsection subsecevorelopubl Evolution: Reloading and Publishing
+
+There seems to be no direct manual reload available, though quitting the
+application and restarting online work seems to do a reload too.
+
+Automatic (repeatedly after some duration) reloads can be set.
+
+
+
+@subsection seckevoexample Evolution: week view of the example.
+
+Evolution connected to our egw example account , gives the view below:
+
+\image html evolutionweek-small.jpg Evolution weekview via the remote icalsrv connected to egroupware.
+
+ Notice that the task hierarchy display (task and subtasks) and the
+percentage complete is not available in Evolution.
+
+@subsection secevoproblems Evolution: problems
+
+
+....TBW....
+
+
+@section secfurtherclients Further Clients
+
+...
+I hope to get reports of other clients too.
+
+
+
+Good luck.
+
+JVL
+
+etc.
+
+
+*/
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-doxydoc-0.9.02.tgz b/phpgwapi/doc/icalsrv/IcalSrv-doxydoc-0.9.02.tgz
deleted file mode 100644
index 9bcc61c92d..0000000000
Binary files a/phpgwapi/doc/icalsrv/IcalSrv-doxydoc-0.9.02.tgz and /dev/null differ
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-doxydoc.tgz b/phpgwapi/doc/icalsrv/IcalSrv-doxydoc.tgz
new file mode 100644
index 0000000000..ef224feff1
Binary files /dev/null and b/phpgwapi/doc/icalsrv/IcalSrv-doxydoc.tgz differ
diff --git a/phpgwapi/doc/icalsrv/IcalSrv-protocoldiscussion.txt b/phpgwapi/doc/icalsrv/IcalSrv-protocoldiscussion.txt
new file mode 100644
index 0000000000..088f32c2c0
--- /dev/null
+++ b/phpgwapi/doc/icalsrv/IcalSrv-protocoldiscussion.txt
@@ -0,0 +1,155 @@
+/*! @page pagewebcaldiscussion Discussion on iCalendar based protocols for Egroupware
+@todo check text and spell errors
+@version 0.0.01
+@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:
+
+
+- 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 1) 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
+
+......
+
+@section secxdelete Post scriptum: 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: 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.
+
+
+
+*/
\ No newline at end of file