[Evolution-hackers] Re: evo calendar extension [Evolution-hackers]

[JT Moree <moreejt pcxperience com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was hoping that the gnomish innards that are opening the files for evo would be able to pull down
the calendar by simply passing http(s):// instead of file:// to the opening routines, thereby
minimal changes to be made to evo.

I notice a thread about subscribing to calendars which I just replied to.  It seems to be working
along the same lines.

Rodrigo Moya wrote:
| 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
|
|

- --
JT Moree
Xperience, Inc.
www.XperienceInc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/HoVmVC8yzAIEMZ8RAqLIAJwOtBoRRl+6CuEMtaXo48z1FM0BtACfWttE
FKbiNTz6LPS4YoQcojkdRvY=
=1JFf
-----END PGP SIGNATURE-----


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.