On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote:
> On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote:
> > We could use Evolution's file-link attachment mechanism by writing into 
> > Evos 
> > file cache from the backend and placing the file paths into the 
> > ECalComponent 
> > when reading calendar objects from the Kolab server, and read attachment 
> > file 
> > data from this same cache when creating a new object with attached files. 
> > We 
> > found a whole lot of issues with this approach (at least for Evo2.30), 
> > which I 
> > can detail if anyone is interested.
>       Hi,
> CalDAV calendar plugin uses this approach, and it seems to work. It's
> surely better than passing rather-long attachments over the wire (D-Bus)
> in both ways. Check the CalDAV sources how it's done there, maybe you
> would be able to mimic that approach.

That's what we're doing in EWS, too. We store the attachments into the
backend's cache directory as obtained by e_cal_backend_get_cache_dir(),
and we set a file:// URL to point to them there. (If you have the MIME
Content-Type: for it, don't forget to put that into a FMTTYPE parameter
in the ical ATTACH property.)

I'm actually not *entirely* happy with that approach; I didn't really
want to fetch all the attachments in advance. I'd prefer to fetch them
on demand, instead.

I was toying with the idea of adding a new URL scheme to represent the
'location' of such attachments, and working out how to make that work in
Evolution. It would presumably need to translate into a DBus call to
evolution-data-server, and some method of passing the data back.

Perhaps the best option is to have a call to EDS which asks it to
'resolve' the attachment into a local file URL instead of a remote one?

For now, I've just stuck with the naïve approach of fetching them all in
advance, but I'd like to have a plan for how to fix that, when it
bubbles up to the top of my TODO list for EWS. And you may want
something similar for kolab?


evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to