-----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.
_______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
