Hi David,
On Thu, Apr 07, 2011 at 01:07:38PM +0100, David Woodhouse wrote:
Personally, no. I'd rather ignore MAPI completely and get on with the
implementation of evolution-ews.
Understandable, though as we've discussed on IRC we don't really have
the option of using that here, at least for
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
On Fri, 2011-04-08 at 09:54 +0200, sean finney wrote:
Sounds like you would be in a good position to do it though.
Because I'm not a gnome dev, I (a) don't have push access, and (b)
am a bit hesitant to go against Milan's wishes, since he's the dev
who is primarily keeping things up for
On Thu, 2011-04-07 at 15:08 +0200, Milan Crha wrote:
Hmm, I still do not like the idea of adding things to gnome-2-32 branch,
I thought I saw you telling that if anyone will complain then you'll not
do that and I thought I complained to it, but I cannot find the email
right now, so I cannot
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
Hi David,
On Fri, Apr 08, 2011 at 09:08:28AM +0100, David Woodhouse wrote:
You're more than welcome to use git.infradead.org if you want. But even
if Milan sees the 2.32 branch as being dead and doesn't want to spend
any of his own time on it (and nobody can blame him for that), I would
hope
On Mon, 2011-04-04 at 08:53 +0200, Milan Crha wrote:
On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote:
That's great; thanks. I'll do a little more testing on the patches
I've cherry-picked into my trees, and then unless someone else has
objected in the meantime I'll push them.
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 there,
I have (perhaps) an unusal setup - I get mail to an IMAP inbox, and
then filter much of it off to local storage, and move the rest manually
as I need to.
I have around 1000 mostly short, text only messages in my IMAP inbox;
and yet:
du -m
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 Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote:
Once this passes muster, I'll push these patches (probably *without* the
NTLM bits, if you're looking closely at what I included) to the
gnome-2-32 branches and perhaps start doing a 'final call' for 2.32.3
candidate bugs/patches.
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,
==5510== 41 bytes in 1 blocks are possibly lost in loss record 8,473 of 17,762
==5510==at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==5510==by 0x3B6A048B52: g_malloc (gmem.c:164)
==5510==by 0x3B6A06101D: g_strdup (gstrfuncs.c:102)
==5510==by 0x1693D7B1: ews_message_info_clone
I have been trying to sort out an import issue at the user-list. I
guess the level of inquiry falls within the hacking domain. I have some
CSV and VCF files of my Contacts created with Windows-7 export tool. I
plan to import the contacts into Evolution running on Fedora Linux
(Lovelock). My
16 matches
Mail list logo
