extern/egroupware_official
1
0
Fork 0
mirror of https://github.com/EGroupware/egroupware.git synced 2024-11-08 00:54:15 +01:00
Code Issues Packages Projects Releases Wiki Activity

icalsrv 0.9.7 todo import limit removed

Browse Source
This commit is contained in:
Jan v. Lieshout 2006-03-14 15:33:27 +00:00
parent ba97e08bcf
commit 60aed02c8c
8 changed files with 531 additions and 201 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
icalsrv.php
View File

@ -9,8 +9,8 @@
* @note <b> THIS IS STILL EXPERIMENTAL CODE </b> do not use in production.
* @note this script is supposed to be at: egw-root/icalsrv.php
*
* @version 0.9.02
* @date 20060214
* @version 0.9.06
* @date 20060313
* @author Jan van Lieshout <jvl (at) xs4all.nl> 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

168
phpgwapi/doc/icalsrv/IcalSrv-Manual-install-howto.txt
View File

@ -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):
<PRE>
<Location /egroupware/icalsrv.php>
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
</Location>
</PRE>
- 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
<code>X-DELETE</code>. 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
*/

99
phpgwapi/doc/icalsrv/IcalSrv-Overview.txt
View File

@ -1,28 +1,73 @@
/*! @mainpage Ical Service for Egroupware
/*! @mainpage Ical Service for Egroupware
@note this is still <b>EXPERIMENTAL, USE AT YOUR OWN RISK! </b> 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
<i>ical client</i> 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 <i> reload </i>)
the data from an a socalled <i> subscribed </i> calendar on the
egroupware server and then read and manipulate it offline. On a
later moment you can upload (aka <i> publish </i>) 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, <b> be warned: when you use the service for
<i>publishing</i> 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!</b>
@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 <i>egroupware</i> and
partly (the documentation only) in module <i>phpgwapi</i>. 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 <i> egwical</i> 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 <i> egwical</i> module from cvs (HEAD).
- Take care that icalsrv.php is <code>.../egroupware/icalsrv.php</code>
(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
<code>/var/www/egroupware</code> and with a http alias <code>egroupware</code> 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 <code>/var/www/egroupware</code> and with a http alias
<code>egroupware</code> pointing to it):
<PRE>
<Location /egroupware/icalsrv.php>
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
<code>X-DELETE</code>. 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
<i>Now with screenshots too!</i>
See @ref pageicalsrvclients for further use and experience with these
clients and supported features <i>Now with screenshots too!!</i>
@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
<code>X-DELETE</code>. 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

58
phpgwapi/doc/icalsrv/IcalSrv-Release-Log.txt Normal file
View File

@ -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)
*/

229
phpgwapi/doc/icalsrv/IcalSrv-clients.txt Normal file
View File

@ -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. <i>importing recurrent events</i> 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 <i>kresource</i> to the resources. You can do this
either via a wizzard or by doing an <i>Add</i>(resource) in the
left-under pane.
The resource must be of the type <i>remote iCalendar</i> 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 <i>Download From</i> and <i>Upload To</i>
fields of the created kresource to one and the same URL as something like:
<code>http://myserver.myorg.org/egroupware/icalsrv.php</code>
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 <i>All Day</i> screen
- the whole day event on thursday is correctly shown in the <i>All Day</i> screen.
@subsection seckorgproblems Korganizer: problems
- Korganizer can get its caches confused.
- Korganizer in default setting does a <i>automatic publish </i> 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. ??) <b>only reading from remote iCalendars is implemented!</b>
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
<i>webcal</i> protocol.
To setup a remote calendar do the following:
- in calendar pane, on the right mouse button menu select <i> New Calendar</i>
- chose a Type: <i>On the web</i> 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:
<code>webcal://username:passwd@myserver.myorg.org/egroupware/icalsrv.php</code>
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.
*/

BIN
phpgwapi/doc/icalsrv/IcalSrv-doxydoc-0.9.02.tgz
View File

Binary file not shown.

BIN
phpgwapi/doc/icalsrv/IcalSrv-doxydoc.tgz Normal file
View File

Binary file not shown.

155
phpgwapi/doc/icalsrv/IcalSrv-protocoldiscussion.txt Normal file
View File

@ -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:
<ol>
<li><b>variant 1)</b> 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><b>variant 2.</b> 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><b>variant 3)</b> 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: 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.
*/