Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Milan Crha
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.
Hope that helps,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread David Woodhouse
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?

-- 
dwmw2

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread David Woodhouse
On Fri, 2011-04-08 at 12:17 +0100, David Woodhouse wrote:
 
 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?

The more I think about this, the more I like it. Add an
X-EVOLUTION-UNRESOLVED-ATTACH: property with details like filename,
content-type and perhaps size, and sufficient information to actually
fetch it on demand. And add a ResolveAttachments() call for the UI to
call, which will turn it into a *real* attachment with a local file://
URL.

Does that seem reasonable?

(For now, though, I'll stick with just fetching the things up front)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Christian Hilberg
Hi everyone,

thanks for the input so far.

On Friday 08 April 2011 David Woodhouse wrote:
 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
 [...] 
 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(),

Just on a very short note:

There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're 
sitting on presently). That means we cannot maintain a backend-private file 
cache with this version, since we cannot inform Evo about it ... is that 
correct?

(Bye)^2,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Milan Crha
On Fri, 2011-04-08 at 15:06 +0200, Christian Hilberg wrote:
 There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're 
 sitting on presently). That means we cannot maintain a backend-private file 
 cache with this version, since we cannot inform Evo about it ... is that 
 correct?

Hi,
basically correct, unfortunately:
http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal.c?h=gnome-2-30#n725

Though you might be able to set full URI in the attachment object and
evo should be able to read it, but not write, probably. Maybe the UI
will create a store for you when creating a new event with attached
files. To be honest, I do not recall details, it's too long time ago
with 2.30.x for me. I would suggest you to try and see.

With respect of fetch on demand, it'll be tricky to achieve, to make
this done right on each operation which deals with the calendar
component in a certain way (operations like copy, move, send and so on).
But there is some API function, probably meant for something like that,
already, the e_cal_backend_get_attachment_list, used by
e_cal_get_attachments_for_comp.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Christian Hilberg
On Friday 08 April 2011 Milan Crha wrote:
 [...] 
 With respect of fetch on demand, it'll be tricky to achieve, to make
 this done right on each operation which deals with the calendar
 component in a certain way (operations like copy, move, send and so on).
 But there is some API function, probably meant for something like that,
 already, the e_cal_backend_get_attachment_list, used by
 e_cal_get_attachments_for_comp.

If at all we can support attachments in some way, and we want to be ready to 
work offline at any time, we'll have the actual data available as 
CamelMultipart message mime part anyways, so not much gain in trying the more 
complex fetch on demand ... as the attachments to Kolab PIM objects reside 
in the same email the actual PIM entry is in (as email attachments). I don't 
think 2.30 IMAPX can fetch just some mime part of an email and leave out 
another (is that even possible with IMAP?), and it is not dictated exactly 
which of the possibly multiple mime parts will be the Kolab XML file carrying 
the calendar data.
  To that end, we presumably cannot take any shortcuts or delay data fetch.

(Bye)^2,

Christian


-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers