Re: evo calendar extension WAS Re: [Evolution-hackers] Evolution as part of groupware projects in ST Louis

[Rodrigo Moya <rodrigo ximian com>]

On Tue, 2003-07-22 at 15:13, JT Moree wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Rodrigo Moya wrote:
> | On Fri, 2003-07-18 at 17:28, JT Moree wrote:
> |
> |>Here is a summary of what we have though about and done about the Calendar functionality related to
> |>Evolution:
> |>
> |>1) Open WebDav/http standards are used by Mozilla calendar, Apple iCal to transport icalendar (.ics)
> |>files.
> |>	Evolution could do the same.  I started hacking Evo to add support for this.  Unfortunately, I was
> |>only on 1.0.8 which was too old to be effective anyway.  I got as far as adding the GUI components
> |>but had some trouble understanding the code for doing the actual work.  May come back to this in the
> |>future.
> |>
> |
> | how did you implement this?
> Well, I didn't actually IMPLEMENT it but my plan was to
> 
> a) add a url field to the new folder/calendar UI (which I did by using glade)
> ~  also add username/password fields for http auth information
> b) add the url to the xml file as that stores metadata about folders for evo
> c) when a calendar folder is accessed, the calendar file is created if it does not exist
> ~   in that routine I was going to check for <url> in the metadata and attempt to pull the file by
> http(s) GET from the url instead of creating a blank calendar.
> d) Eventually, I would add a publish icalendar button that would push the ical file back to the same
> url using http(s) PUT
> 
sounds like a good plan, although I don't know how would this affect the
local storage changes that Ettore is planning. Ettore, would it be
possible to special case the local calendar folders to read the URL
property in the folder-metadata file?

I was also thinking that we could just use a X property on the
calendar.ics file, to specify the remote URL. Thus, when opening the
calendar file, we'd check for that property (X-EVOLUTION-REMOTE-URI, for
instance) and sync the local file with the remote one.

> |
> |
> |>2) Kolab (kolab.kde.org) is the German gov't funded groupware server.
> |>	This method stores all data in IMAP email.  This makes centralized storing and sharing data very
> |>easy.  But this is a new implementation requiring all clients to be changed to support said interface.
> |>
> |>3) A program could be written (and we have some preliminary notes) that translates between Kolab and
> |>ical for CALENDARING.
> |>	A set of programs would have to be given priveledged access to the IMAP data store in order to
> |>translate the IMAP data into icalendar files and vice versa.  This would allow a hacked version of
> |>evo to support both ical/http(s) and Kolab.  The programs would be responsible for hiding private
> |>data during translation.
> |>
> |
> | Evolution's architecture makes it easy to add new calendar backends, so
> | instead of an external program, you could write an Evolution backend
> | that reads the calendar data from the IMAP folders, and convert it to
> | iCalendar back and forth.
> |
> This is very intriguing.  Can I get more information on this approach?  Where can I find APIs and
> documentation?
> 
there is some API documentation in the Evolution source tree. What you
specifically need is to create a CalBackend-based class. Just have a
look at cal-backend-file.c in evolution/calendar/pcs, which is the
implementation of the local backend.

You can, as JP already said, add that CalBackend-based class to the
wombat itself, or you can create a separate process, in which case you
will need to create a EvolutionStorage for each account, and a
EvolutionShellComponent (this one just needed to have Evolution shell
activate the process, so that you can create the EvolutionStorage's).

cheers