Re: [Evolution-hackers] Calendar PIM objects with inlined attachments
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
Re: [Evolution-hackers] Calendar PIM objects with inlined attachments
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
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
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
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
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
[Evolution-hackers] Calendar PIM objects with inlined attachments
Hi everyone. While working on the evolution-kolab plugin, we found that there is no direct support in ECalComponent for attachments inlined into calendar objects. Thus, so far, we can cope with attachments inlined into Kolab calendar objects by hiding them in private ical fields. That way, we can preserve the attachment when writing back some calendar object to the Kolab server which has one attached. The drawback, however, is that we can access this (ical-private) attachment data via ECalComponent neither for reading nor for writing - it will just be invisible to the evolution-kolab plugin user, and they will get no indication that an object carries attachment data (they might just wonder why it takes much time retrieving and storing the object). 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. Before trying anything with the at-least-problematic file cache approach, I thought I'll go ahead and see whether there is anything in the plannings regarding supporting inlined file attachments directly with ECalComponent in latest Evo versions. So far, I did not find anything related on the plannings pages. I'm not clear whether this has been discussed before or whether there are any current plans of extending ECalComponent to support inlined attachments directly (in which case a rather simple change to Evo would allow for supporing inlined attachments in a clean way). I'd like to know your opinions / ideas / ... on that matter. Greetings, Christian PS.:For those who followed the short discussion of the issue on #evolution yesterday, I thought it would be better to record the discussion on the list, so please feel free to paste your thoughts here again - just for the record :) -- 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
