mirror of
https://github.com/EGroupware/egroupware.git
synced 2024-11-08 00:54:50 +01:00
move icalsrv doc into the new module
This commit is contained in:
Jan v. Lieshout
parent
f7c82895f5
commit
972a551f10
@ -1,56 +0,0 @@
|
||||
/*! \page pageicalsrvbugandtodo BUGS and TODOS
|
||||
|
||||
@note This is an early list of bugs and todos. Probably a little bit
|
||||
deprecated now. (see new todo page in relatedpages)
|
||||
|
||||
<PRE>
|
||||
Know BUGS and things todo
|
||||
---------------------------
|
||||
TODO means: should be done/would be nice in a newer release
|
||||
BUG means: known problem needs to be fixed
|
||||
FAIl means: known failure to provide (not easily to be done/fixed
|
||||
|
||||
(note: this list is probably not quite up todate)
|
||||
|
||||
|
||||
release: VERSION 0.9.00 NEED TO UPDATE THIS!!
|
||||
|
||||
|
||||
1) general (V0.9)
|
||||
----------------
|
||||
|
||||
1.1 TODO build egw install/setup system for icalsrv
|
||||
1.2 TODO get it nicely into egw cvs
|
||||
[+/-]1.4 TODO check and generate source code documentation(phpdoc or doxygen)
|
||||
|
||||
|
||||
3.6 TODO/WISH: nothing done yet for vfreebusy, vjournal, notes, components
|
||||
only vevents and vtodos are supported.
|
||||
|
||||
|
||||
2) icalsrv.php (V0.9)
|
||||
--------------------
|
||||
|
||||
[+]2.1 BUG/CHECK repair/improve the http error return (403) (seems to work)
|
||||
[ ]2.3 TODO build user preferences (export/import period setting) gui
|
||||
[ ]2.4 TODO(for v0.9.01 ?) for export: get the agent name from the http header and use
|
||||
to set the ical product field. Then in egwical use it to set the supportedfields()
|
||||
|
||||
|
||||
10.) in used routines from others:
|
||||
|
||||
10.1 BUG Horde_iCalendar(1.2rc6): EXDATE bug
|
||||
-[+]fixed by patch 'exdate ....'
|
||||
10.2 BUG Horde_iCalendar(1.2rc6): standard.php Warning
|
||||
-[+]fixed by patch '...??..'
|
||||
|
||||
10.3 BUG infolog(1.2rc6): datetime is 1 hour wrong for untimed due field in tasks
|
||||
|
||||
11) detected errors/flaws in other programs
|
||||
|
||||
11.1 Korganizer 3.5: recurrence endondate display is interpreted different from egw and
|
||||
mozilla (and probable also rfc 2445)
|
||||
|
||||
|
||||
</PRE>
|
||||
*/
|
||||
@ -1,204 +0,0 @@
|
||||
/*! @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.01R2
|
||||
@author jvl
|
||||
@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 (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).
|
||||
|
||||
- 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):
|
||||
<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 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)
|
||||
- Apple Ical, is reported to be working too. (READ+WRITE)
|
||||
|
||||
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
|
||||
|
||||
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-- by following the guidelines
|
||||
See the egroupware wiki at @url http://www.egroupware.org/bug-reports
|
||||
for more instructions on this)
|
||||
|
||||
This will point you to the sourceforge.net Egroupware buglist at @url
|
||||
https://sourceforge.net/tracker/?group_id=78745&atid=554338 and the
|
||||
dedicated egroupware forums or mailinglist at @url
|
||||
http://www.egroupware.org/forum/?page_name=forum
|
||||
|
||||
What to report? Well you should realize that IcalSrv is --currently--
|
||||
on it self just a rather simple http interface script, that relies for
|
||||
its 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, there a just three other places to look at:
|
||||
|
||||
-# The HTTP error message. <br>
|
||||
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. <br>
|
||||
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 <br>
|
||||
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.
|
||||
Of 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 pageicalsrvbugandtodo
|
||||
-see Todo page in ..
|
||||
|
||||
|
||||
|
||||
have fun
|
||||
|
||||
|
||||
JVL
|
||||
|
||||
|
||||
*/
|
||||
@ -1,58 +0,0 @@
|
||||
/*! \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)
|
||||
|
||||
*/
|
||||
@ -1,229 +0,0 @@
|
||||
/*! @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.
|
||||
|
||||
|
||||
*/
|
||||
Binary file not shown.
@ -1,155 +0,0 @@
|
||||
/*! @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.
|
||||
|
||||
|
||||
|
||||
*/
|
||||
Loading…
Reference in New Issue
Block a user