mirror of
https://github.com/EGroupware/egroupware.git
synced 2025-01-14 01:48:35 +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