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
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
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
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
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
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,
