Re: [Evolution-hackers] Cache encryption
On 03/04/2011 06:40 AM, David Woodhouse wrote: > I'm working on "Enterprise" use of Evolution, and one of the big > requirements is encryption of data at rest. The answer "just encrypt the > whole of the user's home directory" only puts them off for so long. > > So I'm looking at implementing this directly in camel-data-cache, > e-cal-backend-cache, etc. > > I'll probably do the encryption with a randomly-generated key, which > itself is stored locally, encrypted with a password. > > That way, changing the password doesn't involve re-encrypting the whole > of the store; you only need to re-encrypt the master key. It also means > that we can tie the password for the cache to the password for the > server; entering one will allow access to both. > > Hopefully, the changes required to code that *uses* the cache > functionality should be fairly limited. Mostly it should be handled by > extra arguments to camel_data_cache_new(), e_cal_backend_cache_new(), > camel_db_open() and similar functions. > > I'm hoping that it's reasonable to declare that *filenames* are not > sensitive, and that we only need to encrypt the *contents* of files. > Does that seem fair? > for CamelDataCache, the file names already aren't very useful on their own (just hashes of uids, iirc), so you wouldn't need to worry about that ;-) Anyways, do you also plan on encrypting mbox/maildir files? Might make sense... Easiest way to implement this feature in Camel might be to implement a CamelMimeFilter or CamelStream that encrypts/decrypts the content as it reads/writes the data. Implementing it as a CamelStream might be the best approach as it would more easily allow seeking. Hope that helps, Jeff ___ 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] If an account changes, who regenerates the services?
On 10/19/2010 03:52 PM, Matthew Barnes wrote: > On Tue, 2010-10-19 at 14:10 -0500, Federico Mena Quintero wrote: > >> I'm trying to unwind some code in Camel and in Evolution. >> >> The problem I have is that if you change an email account's extra >> options (e.g. imapx's "apply filters to new messages"), then those >> changes don't take effect until you restart Evolution. >> >> That option is a "filter" parameter in a CamelURL - the URL for the >> IMAPX service. >> >> As far as I can tell, the only place where an IMAPX service gets this >> URL is at construction time. However, a breakpoint at imapx_construct() >> only gets hit when I start up Evolution, not afterward (e.g. after >> changing the account's options in the account editor). >> >> There is a lot of code around the account editor to apparently propagate >> changes. But I'm rather lost in the structure. >> >> em-account-editor changes the EAccount in emae_commit(), by calling >> e_acount_import(). Then it does e_account_list_change(). Both of those >> functions emit signals about something changing. >> >> That's where I'm lost. >> >> Does anyone know what links both parts of the code - the account editor >> and the actual construction of Camel services? >> > The 100,000 ft. answer is that trying to represent an account and its > various options as a URL string is a broken concept and another deep > design flaw in Camel. Change any option that results in a different URL > string and Camel treats it as a completely new account, sets up all new > cache storage for it, and doesn't even clean up the old cache. This isn't actually true... or at least it wasn't at one point. There used to be (still is?) a CamelService comparer function that decides if 2 CamelURLs are for the same service. Each provider can override this method. All that needs be done is ignore parts of the url that are insignificant (like the query, for example). The one area where this fell flat was if things like the port changed. One solution to Federico's original query is that you could use the camel_object_setv() API to set new parameters on an existing CamelService (sorta like GObject's getv/setv). I think that currently, a number of options are part of the URL and so changing the URL might make the CamelService want to disconnect/reconnect (assuming it works at all, this part of Camel was never finished). You could modify the service setv() code to be able to "diff" the URLs and see what portions changed to decide whether or not the service needed to reconnect or not and update state. > Camel > needs to have some kind of account object onto which meta-data can be > added and altered. > Sure, but you still have the same problems you have now, just in a different object :-) Jeff ___ 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] Inline PGP encoding in Enigmail
On 07/03/2010 08:28 PM, Kip Warner wrote: > Greetings ladies and gentlemen. There is a thread currently going over > in the Enigmail mailing list that draws on Evolution's design and the > choice made to use PGP/MIME encoding, as opposed to inline, for > sending. > > http://mozdev.org/pipermail/enigmail/2010-July/thread.html > > Subject: [Enigmail] Request for PGP/MIME as default setting > > It may be of interest to those knowledgeable. > I can't believe I still remembered the bug# for this... but, the feature request for sending inline-pgp was: https://bugzilla.gnome.org/show_bug.cgi?id=217541 Anyways, having read the thread on the Enigma list - I have no idea what Robert J. Hansen is talking about wrt to any IRC discussions with some PGP Security group (there was never any such discussion, on IRC or anywhere as far as I can remember). Also, there were never any technical limitations for sending inline-pgp (there were some problems initially with Camel for /verifying/ pgp signatures, but those got worked out as had to be done for PGP/MIME anyway). As far as I remember, the reason we never bothered to implement inline-pgp sending support was more because it was plagued with compatibility problems with the various clients than anything else and really was only ever meant to work with plain-text message /bodies/ (one client or another would pgp sign or encrypt individual attachments too, but most clients weren't able to actually handle that). For example, Outlook's inline-pgp plugin would basically screen-scrape the message body after the user finished composing his/her message, pipe it to pgp, then pipe the signed (or encrypted) output back to the composer, which would then re-HTMLify it (have fun dealing with that!). I would imagine implementing support for sending inline-pgp messages wouldn't be terribly difficult to implement these days if one were so inclined. I'm not sure anyone actually cares though, seeing as how it seems the last request for this feature was from 2004(?). I also seem to remember the Mutt author telling me he was making Mutt default to PGP/MIME quite a few years ago (2002 or 2003 I think), and Mutt users are pretty hard-core so I figured inline-pgp was dead ;-) Jeff ___ 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] Raw access to message
Stefan Schulze Frielinghaus wrote: > On Do, 2010-03-11 at 10:45 -0500, Jeffrey Stedfast wrote: > >> On 03/11/2010 09:16 AM, Stefan Schulze Frielinghaus wrote: >> >>> Hi, >>> >>> Is it possible to get raw access to an email (including header and >>> body)? Or, if that is not possible, raw access to the body of the >>> message? >>> >>> Raw access is important for me because I want to write a plugin which >>> uses some kind of cryptography, e.g. character encoding is important to >>> me. >>> >>> >> You can get the raw message from a CamelMimeMessage object by writing it >> to a stream buffer. >> > > This sounds great. I'm quite new to evolution could you give me a hint > how to do that? I'm starting with an EMEventTargetMessage object where I > can get an CamelMimeMessage object from. But how can I dump this one > into a stream? Writing to a stream requires a buffer of type gchar, but > I have a CamelMimeMessage object and I even do not know the length of > the message. What function calls could I look at? > CamelStream *stream = camel_stream_mem_new (); camel_data_wrapper_write_to_stream (message, stream); It's been 4 or 5 years since I did any evo hacking, so the above code might not be quite right - but it should give you a general idea. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Raw access to message
On 03/11/2010 09:16 AM, Stefan Schulze Frielinghaus wrote: > Hi, > > Is it possible to get raw access to an email (including header and > body)? Or, if that is not possible, raw access to the body of the > message? > > Raw access is important for me because I want to write a plugin which > uses some kind of cryptography, e.g. character encoding is important to > me. > You can get the raw message from a CamelMimeMessage object by writing it to a stream buffer. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
Matthew Barnes wrote: > On Tue, 2010-02-02 at 12:27 -0500, Paul Smith wrote: > >> Anyway, I agree with you that if Evo makes use of this type of aliasing >> then we should definitely add that flag to the default makefile flags. >> Configure can check for it and use it if present. >> > > Done. Although, I imagine many distros have already disabled strict > aliasing optimization due to all the compiler warnings we used to have > about it. > > If GCC or even LLVM ever learns to detect cases like what Jeff ran into > and -warn- about them, I'd love to know about it so I can it to our > already lengthy list of warning flags we build with by default now. > If you want to get warnings about the aliasing stuff, it seems that -Wstrict-aliasing=2 is the one you want. Hope that helps, Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
Xavier Bestel wrote: > On Tue, 2010-02-02 at 18:13 +, Matthew Barnes wrote: > >> On Tue, 2010-02-02 at 12:27 -0500, Paul Smith wrote: >> >>> Anyway, I agree with you that if Evo makes use of this type of aliasing >>> then we should definitely add that flag to the default makefile flags. >>> Configure can check for it and use it if present. >>> >> Done. Although, I imagine many distros have already disabled strict >> aliasing optimization due to all the compiler warnings we used to have >> about it. >> >> If GCC or even LLVM ever learns to detect cases like what Jeff ran into >> and -warn- about them, I'd love to know about it so I can it to our >> already lengthy list of warning flags we build with by default now. >> > > I don't know ... Jeff's demonstration was using obviously wrong C code, > so I'm on GCC side for that one. > It's only wrong if you are targeting c99 (evolution was written to target c89 - that may have changed a bit since I've left the project, but the demonstration code is perfectly legal in c89 and works on all of the big-name compilers). This type of trick is used all over the place. In any case, the workaround is to just specify -fno-strict-aliasing. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
Paul Smith wrote: > On Mon, 2010-02-01 at 11:52 -0500, Jeffrey Stedfast wrote: > >> This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc >> would mistakenly optimize out important sections of code >> when it encountered a particular trick used in a ton of places inside >> Evolution (EDList and pretty much everywhere custom single-linked lists >> are used inside at least Camel and likely other places as well). >> >> A temporary solution is to pass the -fno-strict-aliasing argument to gcc. >> >> Unfortunately, the gcc developers claim that this is not a bug: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907 >> > > It is not a bug in GCC: GCC will compile a program that conforms to the > C standard 100% correctly. Evolution is relying on behavior that is > left as undefined by the standard. Optimizations often cause undefined > code to behave incorrectly, defined as "contrary to the author's > intent", where non-optimized versions of the code "work". That doesn't > mean that the compiler has a bug. > s/C standard/C99 standard/ In C89, a type-cast was a type-cast and had well understood and defined behavior. And in C89, aliasing was legal and widely used. So while it might not /technically/ be a bug in gcc now that it's focusing on c99, it can be argued it's a bug since it broke previous behavior. It can also easily be argued that, in the case of "undefined behavior", a compiler should default to doing what the other (and/or older versions of the same) compilers do. In this case, other compilers (and older versions of gcc) handle aliasing the same, but the new gcc 4.4 behavior changed. Hence why I call it a bug ;-) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc would mistakenly optimize out important sections of code when it encountered a particular trick used in a ton of places inside Evolution (EDList and pretty much everywhere custom single-linked lists are used inside at least Camel and likely other places as well). A temporary solution is to pass the -fno-strict-aliasing argument to gcc. Unfortunately, the gcc developers claim that this is not a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907 Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] mail address validation
Tobias Mueller wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > On 21.01.2010 19:57, Tobias Mueller wrote: > >> I'd be delighted to see an implementation that parses all corner cases, >> i.e. foo/bar=...@example.com or !foo%bar?baz*...@example.com, correctly. >> That might be a challenging Summer of Code assignment ;-) >> >> > Just found this obviously correct RegEx in > http://cpansearch.perl.org/src/MAURICE/Email-Valid-0.15/Valid.pm: > > [snip wall-of-regex] ugh, thanks for reminding me why I hate regex so much ;-) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] mail address validation
Roberto -MadBob- Guido wrote: > On Thu, 2010-01-21 at 13:22 -0500, Jeffrey Stedfast wrote: > >> That won't actually work (at least not very well). The Camel address >> decoding functions assume their input is supposed to be valid and so >> it >> will do whatever it has to do to make it work. It would have to be >> extremely broken for it to fail. >> >> > Is this behaviour the desired one by design, or it is just broken? > By design. But I suppose you could add some flag or something about whether or not to be strict in parsing. Sadly, however, there wouldn't be all that much shared code so it probably wouldn't be worth it. > >> What you'll probably have to do is write similar functionality that is >> much more strict in what it accepts. >> >> > In the first version of the patch > ( http://bugzilla-attachments.gnome.org/attachment.cgi?id=146701 ) I've > provided a routine built on regular expressions (regcomp() and > regexec()). Opinions about that? > > A few comments on the patch: 1. it's best not to compare results to TRUE (e.g. don't use "== TRUE" anywhere. Ever.) because there are a huge number of values for 'true' (TRUE is defined as ! FALSE). 2. I'm not a fan of regex for these sorts of things (designing a regex pattern to parse this stuff is typically non-trivial) and I'm pretty sure that regex pattern is wrong anyway. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] mail address validation
That won't actually work (at least not very well). The Camel address
decoding functions assume their input is supposed to be valid and so it
will do whatever it has to do to make it work. It would have to be
extremely broken for it to fail.
What you'll probably have to do is write similar functionality that is
much more strict in what it accepts.
Jeff
Roberto -MadBob- Guido wrote:
> I was re-working the patch at
> https://bugzilla.gnome.org/show_bug.cgi?id=213724 after reading the
> comment from Milan Crha (that I just now saw, with a pair of months of
> delay :-P ), but it is unclear to me now to validate a mail address
> using camel_*address_* functions.
>
> Here a little test I've done:
>
> //
>
> #include
> #include
>
> static void test (const gchar *address) {
> int ret;
> CamelInternetAddress *addr;
>
> addr = camel_internet_address_new ();
> ret = camel_address_decode (CAMEL_ADDRESS (addr), address);
> if (ret == -1)
> printf ("%s: FAIL!\n", address);
> else
> printf ("%s: OK\n", address);
> }
>
> int main () {
> g_type_init ();
> g_thread_init (NULL);
> test ("madbob");
> test ("2345678");
> test ("mad...@example.org");
> exit (0);
> }
>
> //
>
> The test results always positive, with any string I submit, I'm sure I'm
> missing something but don't know what.
>
> Suggestions?
> Thanks :-)
>
>
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
chenthill wrote: > On Wed, 2009-12-16 at 09:56 -0500, Jeffrey Stedfast wrote: > >> On 12/15/2009 02:46 PM, Chenthill wrote: >> >>> Hi fellow hackers!! >>> I have been working for a while during last week on one the blockers >>> in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 - >>> 'Folder and summary mismatch error'(old one - >>> https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact >>> we have been working as a team to get the blockers down. I have not been >>> able to reproduce the issue or yet find the exact problematic area. >>> >>> The mismatch in the frompos index in the folder summary may be caused >>> by either a threading issue or a crash while storing the indexes. I am >>> still investigating it to find the real cause. >>> >>> >> I don't think it's a threading or crash issue. >> > Looking through the comments from both the bugs and the fixes that have > gone through, i had this thought. Any other clues ? > I'd look into the situation where the user expunges a folder. When the mbox gets rewritten, maybe the from_offset values aren't updated or something to reflect the new offset. That's all I can think of at the moment. I'm sure this avenue has probably been explored before, but maybe something got missed. > Thinking about the amount of time this bug has been there for (primarily > with our mbox implementation) , I thought of making some change which > could benefit more rather than trying to just fix this. This might not > be an ideal way to think though :) > Well, either way the bug should be fixed. Switching to Maildir is arguably a good choice regardless, though. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
Milan Crha wrote: > On Wed, 2009-12-16 at 19:50 -0500, Jeffrey Stedfast wrote: > >> The standard way to nest Maildir folders is such: >> >> Maildir/ >>cur/ >>new/ >>tmp/ >>.GNOME/ >> cur/ >> new/ >> tmp/ >>.GNOME.Evolution/ >> > > maybe, but Evolution doesn't use this model, it is creating subfolders > directly, like: > Maildir/ >cur >new >tmp >folder1 > cur > new > tmp > folder2 > > Which makes: >Inbox >folder1 > folder2 > Ugh. I'm pretty sure the standard way of doing it is the way I noted above. > How do you create a folder on the same level as Inbox with your model? > I'm sure this has been solved before, but even if it hasn't, some IMAP servers have the same "limitation". Keep in mind that the view doesn't have to be a 1-to-1 mapping of the model. > As far as I understand it the leading dot means it's an Inbox subfolder, > not only a folder itself. We want it for Send/Draft/Outbox folders at > least. I thought to workaround it by starting maildir hierarchy for > local folder not at '.', but at './Our-Inbox'. Kinda nasty, I know. > I wouldn't suggest that. One option is to just special-case Outbox, Sent, and Drafts. Even though they would be ~/Maildir/.Outbox/, for example, you could treat it as though it were on the same level as ~/Maildir (aka Inbox). > If there will be any change in the folder layout for maildir, we should > keep some option for backward compatibility, but that's obvious. > Yep. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On 12/17/2009 05:36 AM, Milan Crha wrote:
> On Wed, 2009-12-16 at 19:56 -0500, Jeffrey Stedfast wrote:
>
>> Does it really crash? It used to just regenerate the summary files.
>>
> yes, on out of memory, as it tries to allocate a very large memory block
> due to misreading items.
>
Ah, okay, I can see that happening. Depending on what is allocating the
memory, it might be possible to switch from g_malloc() to g_try_malloc()
to avoid this problem. However, if it is inside GPtrArray or something,
might not be doable.
>
>
>>> b) you cannot just drop it and regenerate, because it holds some
>>> information for local providers, like labels, tags and such.
>>>
>>>
>> The point of the version info was so that you could do things like:
>>
>> if (summary->version < CAMEL_64BIT_SUMMARY_VERSION) {
>>off_t offset;
>>camel_file_utils_load_off_t (file, &offset);
>>info->offset = offset;
>> } else {
>>camel_file_utils_load_int64 (file, &info->offset);
>> }
>>
>> If you do this, then you don't actually lose any information.
>>
> I do not think the above will work together with defaulting to LARGEFILE
> compile flag, but the other way would, like defaulting to load_int32 for
> older summaries and reading off_t for new.
What you will want to do is always save file offsets as int64 in the new
version, no matter whether LARGEFILE support is enabled or not.
You also want to keep using load_off_t() for the older versions because
that's what the code does now. If you make it use load_int32() it will
break for 64bit systems or any system using LARGEFILE support (e.g.
anywhere off_t is 64bit).
> I'm wondering whether some
> distro has the largefile support enabled these days, as if so, then the
> decision what to use as an off_t size isn't that easy. Maybe they have,
> or it's enough to compile under 64 bit to have the size changed.
> I didn't try this, I just suppose because of reported issues.
>
As long as you bump the summary version number, this isn't a problem if
you do something along the lines of the code I posted above.
Keep in mind, the new summary code will have to *always* save offsets as
8 bytes as opposed to sizeof (off_t), but that's ok - that's what you
ultimately want anyway (you want the file format to stay the same no
matter if LARGEFILE is enabled or not).
Actually, the summaries aren't even saved in the binary summary format
anymore, are they? They're in some sqlite db now, right?
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On 12/16/2009 02:40 PM, Milan Crha wrote:
> On Wed, 2009-12-16 at 11:35 -0500, Jeffrey Stedfast wrote:
>
>> The summary files would have had this problem, but they would have
>> just been regenerated, so not really an issue.
>>
> Hi,
> a) it's similar as moving from 32bit to 64bit architecture or the other
> way; evo crashes for these situations, because the version is fine, but
> it doesn't know whether the previous one was a 32bit or 64bit machine,
> aka whether it should do some "translation" or not. (and doing
> translation is not as that simple for usage of functions which are doing
> sizeof(...); not a problem with db-summary, but still might be with
> indexes and store summaries, I didn't check that.)
>
Does it really crash? It used to just regenerate the summary files.
> b) you cannot just drop it and regenerate, because it holds some
> information for local providers, like labels, tags and such.
>
The point of the version info was so that you could do things like:
if (summary->version < CAMEL_64BIT_SUMMARY_VERSION) {
off_t offset;
camel_file_utils_load_off_t (file, &offset);
info->offset = offset;
} else {
camel_file_utils_load_int64 (file, &info->offset);
}
If you do this, then you don't actually lose any information.
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On 12/16/2009 02:50 PM, Milan Crha wrote: > On Wed, 2009-12-16 at 17:34 +0530, Srinivasa Ragavan wrote: > >> Btw, just don't remember well, but Milan did a research of the same, >> moving from mbox to maildir. Milan do you remember the points to >> consider? It will be helpful >> > Hi, > I'm sorry, I forgot those, it's quite long time ago. Some of them were > mentioned in this thread, like: > - cannot use ':' in a file name for Windows > - cannot create a subfolder of an Inbox > The standard way to nest Maildir folders is such: Maildir/ cur/ new/ tmp/ .GNOME/ cur/ new/ tmp/ .GNOME.Evolution/ cur/ new/ tmp/ .GNOME.Evolution.Hackers/ cur/ new/ tmp/ .Xorg/ cur/ new/ tmp/ this will give you the following folder tree: Inbox GNOME Evolution Hackers Xorg > - cannot use folder names 'new'/'cur'/'tmp' as those are maildir's > see above. > - should choose folder hierarchy model (there is some already, but it >has some issue, but I'm not sure what it is) > see above. > - recently also some slowness for refresh of large folders (should be >partially fixed, but not fully, if I recall correctly) > is this related to readdir() performance? > I've a feeling there were more, but I forgot them. :( > > As others in this thread I would also prefer to use maildir instead of > creating new provider for this. The maildir would be fixed and changed > slightly to satisfy evo needs for those above issues, but otherwise > there's no difference for mbox-per-file, as maildir does pretty the same > thing (message-per-file). > I agree. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
Jeffrey Stedfast wrote: > Matthew Barnes wrote: > >> there was concern that simply turning it on would somehow break existing >> installs. I'm fuzzy on the details, but vaguely recall it being about a >> field size in some binary file being dependent on sizeof(off_t), which >> would change with LARGEFILE support enabled and thus break the binary >> format. >> >> > > The summary files would have had this problem, but they would have just > been regenerated, so not really an issue. > Also, this is why the summary files had versioning info. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
Matthew Barnes wrote: > On Wed, 2009-12-16 at 09:56 -0500, Jeffrey Stedfast wrote: > >> This just means the proper LARGEFILE flags are not being used at >> compile time. Either EDS's configure isn't doing proper checks or else >> Evolution itself isn't doing proper checks and there is some sort of clash. >> >> An easy way to fix this is to do what I did with GMime, which is to >> simply make all public stream APIs that use off_t use goffset instead >> (I'm sure Matthew will want to do this anyway). Then the problem is >> much simpler to solve - just make sure that Camel uses the proper CFLAGS >> for LARGEFILE support (which you can steal from GMime's configure >> scripts). >> > > IIRC, the issue is LARGEFILE support is still disabled by default, and > Ah. I'd still suggest switching over to goffset rather than using off_t in the public API (and for internal state on indexes and wherever else). > there was concern that simply turning it on would somehow break existing > installs. I'm fuzzy on the details, but vaguely recall it being about a > field size in some binary file being dependent on sizeof(off_t), which > would change with LARGEFILE support enabled and thus break the binary > format. > The summary files would have had this problem, but they would have just been regenerated, so not really an issue. > Unfortunately I don't remember which file that was an issue in. It may > have already been addressed by the move to a summary database, or I may > just be propagating false rumors. > There may have been other files, but the summary files would definitely have been affected (tho it would not have been problematic). Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On 12/15/2009 02:46 PM, Chenthill wrote: > Hi fellow hackers!! > I have been working for a while during last week on one the blockers > in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 - > 'Folder and summary mismatch error'(old one - > https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact > we have been working as a team to get the blockers down. I have not been > able to reproduce the issue or yet find the exact problematic area. > > The mismatch in the frompos index in the folder summary may be caused > by either a threading issue or a crash while storing the indexes. I am > still investigating it to find the real cause. > I don't think it's a threading or crash issue. > Looking at other issues such as, > https://bugzilla.gnome.org/show_bug.cgi?id=522433 - 'Fails opening mbox > >> 2GB', just got a thought if we could solve both the issues by, >> > This just means the proper LARGEFILE flags are not being used at compile time. Either EDS's configure isn't doing proper checks or else Evolution itself isn't doing proper checks and there is some sort of clash. An easy way to fix this is to do what I did with GMime, which is to simply make all public stream APIs that use off_t use goffset instead (I'm sure Matthew will want to do this anyway). Then the problem is much simpler to solve - just make sure that Camel uses the proper CFLAGS for LARGEFILE support (which you can steal from GMime's configure scripts). > Approach #1, > migrating local storage from mbox to maildir format. With maildir I have > heard about two issues, > > * Not able to create subfolders under INBOX - > https://bugzilla.gnome.org/show_bug.cgi?id=536240 . > This is just a bug and it should be fixed regardless. > Approach #2, > Migrate from a single mbox file per folder to mbox per email. Srini > mentioned an advantage that this would avoid the file renames that > maildir does. I think this is much like how other remote providers in > evo store the email. > I'm not sure if you mean the CamelImapMessageCache way or CamelDataCache (as someone else mentioned in this thread). Either way, it seems a messy way of organizing messages as well as costly in terms of inodes (and possibly in wasted disk space, although Meeks' email seems to suggest file-per-message might not be that bad). Then there's the problem of getting mail into and out of this storage scheme. (Note: Maildir would be less inode-intensive) I think that Evolution should always choose to use a standard mailbox format rather than make up its own. So if the consensus is to move away from mbox, then my vote would be with Maildir. We originally chose mbox (when I say originally, I mean for 2.x), it was largely done because most other popular clients also sued mbox. One of the things we had to do was to figure out a way to structure an mbox folder tree, and the way I did that was to mimic Thunderbird's folder layout (which was quite nice). IMHO, this was an added bonus because I think that Thunderbird was the most likely candidate for people to be switching to/from as it was the other major mail client at the time - making migration as simple as a cp -r (or an mv) is pretty slick. Performance gotchas with Maildir: There were some comments earlier in this thread about not wanting to use Maildir because of performance problems with rename(). It's not the rename() which is the performance problem, but rather the fact that once a message file is renamed, the client must scan the directory listing(s) looking for the new name (strcmp()ing everything up to the ':' iirc). If the volume of mail gets large enough, this could potentially be problematic. I believe it was problematic on ext2, but things may have changed since then. I should point out that this is ONLY a problem if other clients are involved because Evo could (should) keep track of the name changes in its summary files. Hope this helps, Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Manifesto
Matthew Barnes wrote: > With work on Bonobo removal wrapping up, I've finally started taking a > closer look at Camel (Evolution's mail storage and networking library) > and laying out plans for where I'd like it to go over the short and long > term, with the ultimate goal of splitting it off as a useful standalone > GNOME library (but we're a long way from that). > > As usual I'm taking a bottom-up approach, starting with basic cleanup > chores (both code and development policies) and building up from there. > Here's some of my thoughts: > > > Backward Compatibility Policy > - > > A reverse dependency search in Debian and Fedora reveals the only > external projects currently linking to Camel are mail-notification, > evolution-jescs and Anjal (please correct me if I've missed any). > > That tells me that until Camel moves out of its parents' basement and > matures into an real, honest-to-goodness library, fixing its interface > is more important than maintaining backward compatibility. Deprecation > periods for obsolete API are not necessary, in my opinion. The few > external projects linking to Camel will just have to keep up with the > changes every six months. > I think it's a worthy goal to separate Camel out of Evolution. > That's not a license to go hog wild though. Some caveats: > > 1) The soname -must- be kept accurate. If you break the API or ABI, >increment the soname when you commit the break. It doesn't matter if >the break doesn't affect external projects, nor even if it's already >been incremented since the last point release. Bump it anyway. >"Always bump" is an easy policy to remember. It makes our own daily >development run smoother, and helps ensure a release doesn't slip out >with an inaccurate soname. > >If you're not sure if your patch requires a soname increment, please >ask in IRC or Bugzilla. Patch reviewers should try to remember too. > > 2) If you must break the API, try to do so in a way that things will >fail noisily at build time rather than mysteriously at run time. For >example, if you want to change the behavior of an existing function, >it's better to rename the function or change its parameter list so >that stale Evolution code will fail to build. > > 3) Camel started life as a general purpose mail library and I'd like to >try to get back to that. Camel has become too Evolution-centric in >my view, with too many quick-fix hacks for Evolution bugs that would >not be appropriate for a general purpose mail library. I will clean >these up as I find them, but try to keep that in mind when altering >the API yourself. > I'm not sure what Evolution-specific quick-fix hacks you mean? > > Migrate to GObject > -- > > Camel's homegrown type system will be replaced with GObject so that > introspection and D-Bus + language bindings are possible. CamelObject > will remain (for now), but as a subclass of GObject. The redundant > parts of CamelObject will be removed. > Worthy goals... there are some things like CamelObjectBag and such that don't have an equivalent in GObject. > I'm also following GLib and GTK+'s example of sealing up public instance > data in private sections and enforcing that only its top-level header > file be included outside of Camel (including the providers). Unlike > GLib and GTK+, there will be no transition period. > Okay. > This will give us a lot more freedom to reorganize the library and > refactor code without disturbing the ABI. Debugging is also easier when > you can trap data accesses through "get" and "set" functions. > Sure, but I don't think any code actually goes behind any get/set method's back at the moment (or at least didn't back when I worked on Camel). Regardless, I'm cool with the proposed changes... > I've been chipping away at this as a side project for the past year (it > was a good mindless activity when I got burned out on Bonobo removal), > and I recently published my results to git.gnome.org as a branch named > "camel-gobject". The CamelObject conversion is finished -- including > all the boilerplate changes in the subclasses -- but I haven't finished > sealing up the API. > > The branch probably won't land until 2.31 at the earliest. The backward > compatibility policies I described above would be in effect thereafter. > > > Kill CamelStream > > > This is a distant future goal and will have to happen gradually, but I > would like Camel to shift to a single-threaded design where all file and > network operations directly use or are derived from GIO's asynchronous > file and stream APIs. SSL support is currently under development for > GIO, and that's the only missing piece I see at the platform layer. > > I realize this is a drastic course correction and will require rewriting > all the providers and much of the mailer code in Evolution, but I firmly > believe that the o
Re: [Evolution-hackers] camel-folder-summary.c - 64bit-ness ...
Michael Meeks wrote:
> Hi guys,
>
> I was just trying to reproduce some migration performance tests with my
> mbox and summary data rsync'd from a 32bit machine to a 64bit machine.
>
> Surprisingly this appears to crash immediately.
that's not good :(
> Looking at the
> camel-file-utils.c code I was surprised to see simultaneously an
> apparent concern for network byte ordering:
>
> camel_file_util_encode_fixed_int32 (FILE *out, gint32 value)
> {
> guint32 save;
>
> save = g_htonl (value);
> if (fwrite (&save, sizeof (save), 1, out) != 1)
> return -1;
> return 0;
> }
>
> and also things like:
>
> CFU_ENCODE_T(time_t)
>
> that appear to generate data based on the sizeof the platform's time_t
> - on my 64bit machine time_t is 8 bytes, on 32bit it is only 4.
>
yea, unfortunately the old summary format wasn't designed with 32/64 bit
compat. Now that a lot of people are moving from 32bit to 64bit as they
upgrade to 64bit x86's, it would probably be good to look into.
Although, to be fair, summary files can be re-generated pretty easily.
Unfortunately, for IMAP, while it may be "easy", it's not very fast :(
> Presumably this summary code is made obsolete by the new SQLite summary
> code - and modulo some data as to what architecture a file was written
> by it's perhaps less than obvious how to fix this.
nod. the only idea I can come up with is having some logic in the
loading code that tries to figure out why loading failed and to see if
it might have something to do with 32bit vs 64bit int sizes in the
summary file.
Not sure how doable it is.
> Also - why we're not
> using fgetc_unlocked in these tight loops I don't know.
>
isn't that a GNUism? To be honest, I didn't even know the function
existed until a year or so ago when I was looking into Mono vs Java I/O
performance based on the Debian Language Shootout tests. I happened to
look at the C implementation and saw fgets_unlocked() and looked into
it. IIRC, replacing it with fgets() didn't make any noticeable
difference in performance. I just figured it was a soptimization ;-)
> I guess I need an old evo. version to re-build all my summaries for
> 64bit now; or am I barking up the wrong tree ?
>
I would imagine so, yea.
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all
Philip Van Hoof wrote:
> On Mon, 2009-01-05 at 08:25 -0500, Jeffrey Stedfast wrote:
>
>
>> migrating away from the IMAP specific data cache would be good.
>>
>
> Yes. I think IMAP and the local providers are the only ones that are
> still using a specialized datacache.
>
> The IMAP4 one, for example, ain't using a specialized one.
>
>
>>>> b) migrate away the mbox data cache (the all-in-one file crap)
>>>>
>>>>
>>> I'm all for it. Once I thought of doing this, but the options were like
>>> Maildir or a format of one mbox file per mail in a distributed folder
>>> [CamelDataCache sort of format, like imap4/GW/Exchange]. But IIRC Fejj,
>>> had some concern like, Local still might be good to be held in a
>>> 'standards' way. I know it hurts us on expunge/mailbox rewrite etc.
>>>
>>>
>> what mbox data cache? CamelDataCache would probably be the best cache to
>> use for IMAP.
>>
>
> Although I would change CamelDataCache to store individual MIME parts as
> separate files instead of files that look like a single-mail MBox file.
>
it's really just the raw message/rfc822 format, not really mbox -
there's no "From " line for example.
that doesn't need to be part of the cache logic. that can be part of the
key.
> I would also decode the separate MIME parts before storing if the
> original E-mail had them encoded (which is usually the case, and always
> for binary attachments). This to make it more easy for metadata engines
> to index the MIME parts, and to allow such to do this efficiently.
>
> Perhaps also to reduce disk-space, as encoded consumes more disk-space,
> but that is for me just a nice side-effect.
>
> So my format would create a directory foreach E-mail, or prefix each
> MIME part with the uid. Perhaps
>
> INBOX/subfolders/temp/1. // headers+multipart container
> INBOX/subfolders/temp/1.1 // multipart container
> INBOX/subfolders/temp/1.1.1 // text/plain
> INBOX/subfolders/temp/1.1.2 // text/html
> INBOX/subfolders/temp/1.2.1 // inline JPeg attachment
> INBOX/subfolders/temp/1.BODYSTRUCTURE // Bodystructure of the E-mail
> INBOX/subfolders/temp/1.ENVELOPE // Top envelope of the E-mail
>
sure, this can be done with the key tho. instead of using the uid as the
key, use uid.1 or uid.1.2 etc
> ps. Perhaps I would store 1.BODYSTRUCTURE in the database instead. I
> would probably store 1.ENVELOPE in the database (like how it is now).
>
yea, I think it makes sense to store BODYSTURCTURE in the folder summary.
> I would probably on top of storing BODYSTRUCTURE and ENVELOPE in the
> database also store them in separate files. Even if most filesystems
> will consume 4k or more (sector or block size) for those mini files.
>
> To get the JPeg attachment:
>
> $ cp INBOX/subfolders/temp/1.2.1 ~/mommy.jpeg
>
> $ exif INBOX/subfolders/temp/1.2.1
> EXIF tags in 'INBOX/subfolders/temp/1.2.1' ('Intel' byte order):
> +--
> Tag |Value
>
> +--
> Image Description |Mommy with cake at birthday
> Manufacturer|SONY
>
> Model |DSC-T33
>
> ...
>
> $ tracker-search -s EMails birthday
> Results:
> email://u...@server/INBOX/temp/1
> email://u...@server/INBOX/temp/1#2.1
> ~/mommy.jpeg
>
>
> [CUT]
>
>
>> this can cause problems if you need to verify signed parts because
>> re-encoding them might not result in the same output.
>>
>
> Ok, for signatures I guess we can make an exception and keep then
> encoded in their original format then.
>
>
>>>> For Maildir I recommend wasting diskspace by storing both the original
>>>> Maildir format and in parallel store the attachments separately.
>>>>
>>>> Maildir ain't accessible by current Evolution's UI, by the way.
>>>>
>>>> For MBox I recommend TO STOP USING THIS BROKEN FORMAT. It's insane with
>>>> today's mailboxes that easily grow to 3 gigabytes in size per user.
>>>>
>>>>
>>> I second your thoughts for MBox stuff.
>>>
>>>
>> Eh, I think mbox works fine but I can understand wanting to move to
>> Maildir which is also fine :-)
>>
>
> Maildir doesn't store individual MIME parts separately. So Mailbox is
> equally hard to handle for metadata engines as MBox is. Only difference
> with MBox is that we need to seek() to some location.
>
> So Maildir doesn't make it possible for us to let app developers
> implement indexing plugins easily, like a typical exif extractor.
>
I guess, but they could just link with gmime or camel :p
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all
Srinivasa Ragavan wrote: > Hey Philip, > > [Im lagging in my mail-replies, still a lot to go, due to my 3 week > vacation.] > > On Fri, 2009-01-02 at 13:25 +0100, Philip Van Hoof wrote: > >> Hi there evos, >> >> For an EPlugin that I'm working on I will need a Camel API to get the >> filename of the cache. >> > > Sure and the patch seems fine to me, but the Exchange portion of the > patch is missing. It should be similar/simple. > >> I will attach a patch that adds this API. The EPlugin that I'm developing is >> available at Bug# 565091 and more information about it can be found at >> >> http://live.gnome.org/Evolution/Metadata. >> >> >> I added a bug for tracking this request: >> >> http://bugzilla.gnome.org/show_bug.cgi?id=566279 >> >> I know that for maildir (cur, tmp, new) and mbox (seek position) it's a >> little bit controversial to return a filename. For maildir I always use >> the cur-file one and for mbox I added "/!seek_pos" to the end of the >> returned filename. >> >> The reason why I need this is that for indexing already cached E-mails, >> Tracker will MIME parse what we can MIME parse. For example filenames >> and Exif data of attached images is stolen out of the cached items, to >> be made searchable. >> >> We don't want to require Evolution to eat all the code involved in >> indexing massive amounts of file formats. Best thing we can do right now >> is to simply pass the filenames over IPC. >> >> We STRONGLY recommend to the Evolution team to: >> >> a) migrate away the IMAP specific data cache (see c to store separate parts) >> > I thought we already store parts separate. Is is just about the encoding > or more than that? I seriously don't have an idea on this. May be Fejj, > Sankar, Matt can add on it. > migrating away from the IMAP specific data cache would be good. > >> b) migrate away the mbox data cache (the all-in-one file crap) >> > I'm all for it. Once I thought of doing this, but the options were like > Maildir or a format of one mbox file per mail in a distributed folder > [CamelDataCache sort of format, like imap4/GW/Exchange]. But IIRC Fejj, > had some concern like, Local still might be good to be held in a > 'standards' way. I know it hurts us on expunge/mailbox rewrite etc. > what mbox data cache? CamelDataCache would probably be the best cache to use for IMAP. > >> And to >> >> c) invent a better storage format that doesn't store the attachments in >> server's (usually) Base64 encoding. The one format to rule them all. >> >> Instead store the encoded attachments in decoded format (original file >> format). This will reduce diskspace (encoding increases diskspace usage) >> and will make it more easy to scan the original file for XMP and Exif >> information. Don't try to gzip or whatever anything. None of that makes >> any sense (original files are usually compressed ideally already). >> >> For example: devices that want to compress have filesystems that do this >> for you. Don't be silly trying to do this yourself. >> >> By storing the encoded version the only thing you currently gain is that >> the feature "view E-mail source" doesn't need to recode the attachments. >> >> This ain't a much-used feature. It doesn't have to be fast, at all. >> >> No it doesn't. Really it doesn't. >> > Is thatz it? I need some other opinions, I don't have much thoughts > here. Sankar, Matt, Fejj? > this can cause problems if you need to verify signed parts because re-encoding them might not result in the same output. >> For Maildir I recommend wasting diskspace by storing both the original >> Maildir format and in parallel store the attachments separately. >> >> Maildir ain't accessible by current Evolution's UI, by the way. >> >> For MBox I recommend TO STOP USING THIS BROKEN FORMAT. It's insane with >> today's mailboxes that easily grow to 3 gigabytes in size per user. >> > I second your thoughts for MBox stuff. > Eh, I think mbox works fine but I can understand wanting to move to Maildir which is also fine :-) > >> Once all start using the CamelDataCache API, implementing that new >> format and implementing converters wont be very hard. >> >> For existing CamelDataCache users it's just one format to convert. For >> IMAP, mbox, Maildir and mh it's indeed a few extra formats to handle >> using a conversion. Wont kill you to implement that, and, I'll help. >> > > Thatz so nice of you to help us :-) > > -Srini > > > Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] unsubscribing to evolution-mail-maintainers
Can anyone tell me how to go about getting unsubscribed from the evolution-mail-maintainers list? Thanks, Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [CamelStore] clarifying of documentation becomes a minor change of code
On Mon, 2008-09-01 at 18:19 +0200, Paul Bolle wrote:
[snip]
> void
> camel_store_free_folder_info (CamelStore *store, CamelFolderInfo *fi)
> {
> + if (!fi)
> + return;
> +
that null-check should probably go after the g_return below:
> g_return_if_fail (CAMEL_IS_STORE (store));
>
> CS_CLASS (store)->free_folder_info (store, fi);
>
other than that, it's ok with me.
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution: Taking forward...
I just wanted to chime in and say AWESOME!!! :-) It is my hope that now that Evolution no longer requires assignment, that we'll see more developers get involved with improving it - who knows, maybe someone will even contribute an uber IMAP implementation? :-) Jeff (retired Evolution hacker) On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote: > Hello guys, > > We have had a set of problems that we are carrying around for some time like : > > * Copyright assignments, which is not the best way looking for the > future of Evolution. It sucks and sort of limits contributions to Evolution > and we wanted to drop it. > * The current licensing incompatibility issues of Evolution with > Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the > new mapi based connector being developed for Exchange 2007. > > So here is the plan : > > * Drop Evolution copyright assignments and make it really easy to > contribute to Evolution > * Move Evolution licensing to "LGPL v2 and LGPL v3" to let us re-use > the code more easily around the platform. This also moves us closer to > Thunderbird's MPL/LGPL model. > > We think this is good for Evolution and (of course) we continue to invest in > Evolution. We are also working to ensure we have the rights to re-license all > of the code. We will do the licensing/header changes as we audit the code > ownership situation. > > It would be really helpful if you can post a public/explicit mail with > permissions to do it, or code pointers - if you think you wrote a piece of > Evolution code & object. > > We are really excited about this and we feel this would really help Evolution > a lot. We need your support now for making this change and to take Evolution > to great heights. > > Thanks for your contributions and support. > > -Srini. > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
is anyone else getting duplicates of this message every few days? This has been going on for months and is a bit annoying. Is the mailing-list server looping or what? Jeff On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote: > Hello, > > did the slightly inflammatory subject catch your attention? Good, please > keep reading... ;-) > > Details can be found in multiple Bugzilla entries, the most important > one apparently being this one: > http://bugzilla.gnome.org/show_bug.cgi?id=301363 > > Let me summarize the current situation: since 2.12, Evolution uses the > host's timezone information. This is only a partial solution. For events > created by other programs the incomplete and sometimes obsolete > VTIMEZONE information is still used. > > As an example, take the two attached meeting invitations. The "2006" one > is a real stripped down invitation from Outlook, created in 2006 using > the old DST rules. The newer "2008" one uses the current rules. > > When importing "2006" into a local calendar file, the "GMT -0600 > (Standard) / GMT -0500 (Daylight)" timezone definition is added to the > calendar. When importing "2008", the timezone definition is not updated. > This has the effect that the new meeting is not displayed correctly in > the calendar. But replacing the timezone definition would not be correct > either, because it would break the mapping of past events of the old > event before the DST change in 2007. > > This is a conceptual problem of how timezone definitions are handled: > they should be attached to events, not to calendars. The Itip formatter > plugin demonstrates that: it uses the timezone definition included in > the meeting invitation and correctly calculates the local times for both > events. > > One could argue that the sending program is at fault: it could have used > a different TZID after changing the timezone definition. Alternatively > it could have sent a more complex VTIMEZONE which also includes the > historic rules. I believe both causes other problems in practice. > Speculating about it is futile anyway and won't change the meeting > invitations that Evolution has to deal with. > > Besides, don't blame Outlook too much: Evolution >= 1.12 now does > exactly the same thing. For example, a meeting invitation now uses > "/softwarestudio.org/Tzfile/America/Los_Angeles" and only includes the > current rules for daylight saving transitions. > > The "2006" event demonstrates another problem: the recurrences during > those weeks in 2007 and 2008 where old and new rules differ are not > calculated correctly. > > A user of SyncEvolution and ScheduleWorld reported timezone issues here: > http://www.scheduleworld.com/jforum/posts/list/1543.page > > In the ensuing discussion Mark Swanson from ScheduleWorld suggested that > all clients should use the same TZIDs to reference a complete local > Olsen database. I don't think that this is doable in all cases, but I > think Evolution should at least try it. Without further ado, here's my > proposal how importing events into Evolution should work. If you agree, > then I can try to create a patch. > > For each TZID used in an event, Evolution should try to find the > corresponding system timezone via a fuzzy search. If the TZID already > follows the pseudo-standard set by the Olsen database, then the > comparison could be based on the local part, e.g. "America/Los_Angeles". > This solves the problem of importing events generated by ScheduleWorld > (which currently uses a /scheduleworld.com// prefix and > thus is not mapped to system time zones). > > If the TZID is in some other format (like the ones used by Outlook), > then a hard-coded table could do the mapping. This would solve the > problem with the "2006" example. This step is kind of ugly and optional: > I myself would argue that for such recurring meetings the sender is > responsible for sending an update with the current VTIMEZONE. In my > experience this really happened in many cases beginning of 2007. > > If a match is found, then the event is stored with the original TZIDs > replaced by the matching system ones. The VTIMEZONE is discarded. > > If no match is found, then the custom VTIMEZONE definition must be > stored in the calendar. I don't think that the EDS infrastructure should > be changed. It would break APIs and be a lot of work to implement, plus > it would store multiple redundant copies of identical VTIMEZONE > definitions, leading to worse performance. > > What I suggest instead is the following scheme: check whether the > calendar already has a VTIMEZONE with a given TZID. If one is found, > check whether the timezone definition is really identical. If it is, all > is well. If not, then rename the new timezone by attaching " ". > Repeat the check and renaming until a 100% match is found or the > timezone can be stored without colliding with an existing timezone. Then > proceed with importing the event with renamed TZIDs. > > I believe that this could be
Re: [Evolution-hackers] Is there any APIs for fetching the GPG Key id from a CamelMimeMessage ?
It doesn't look like there's any current API to do it. I suggest you look at gmime svn's gmime-cipher-context.[c,h] and gmime-gpg-context.[c,h], specifically the code that fills in the GMimeSigner structures and just make CamelCipherCertInfo struct closer to the GMimeSigner struct. Jeff On Wed, 2008-06-25 at 17:10 +0800, Zhang Shunchang wrote: > hi,all > i am doing something about the GPG Keys in Evolution. i want to get the > GPG Key ID(8 hex digit) from the message if this message was signed. > > i found that there is a valid field in CamelCipherValidity structure, > where there is a sign.description field, which points out: > > Version: GnuPG v2.0.9 (GNU/Linux) > gpg: armor header: > gpg: Signature made Wed 18 Jun 2008 06:17:27 AM CST using DSA key ID > AA208D9E > gpg: Can't check signature: No public key > == > > how can i get exactly the GPG Key ID? is there any public API or any > good method? > > Thanks in advance! > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libdb from EDS source
On Fri, 2008-06-13 at 17:55 +0100, Ross Burton wrote: > On Mon, 2008-05-05 at 10:58 +0530, Srinivasa Ragavan wrote: > > Ross, > > > > I had a chat with JP and He pointed me to a old README. > > > > === > > The issue was around no backwards compatability, from the old README: > > In my experience recently Berkeley DB has been a lot more forgiving > recently. Note that Debian links EDS against DB 4.5, and in the past > has linked against 4.4, 4.3, 4.2 instead of the EDS-bundled 4.1 without > any problems. > > EDS has code to handle database upgrades if the file format does change. > Yes, this means that the user can't then use the same data file on > another machine if it uses an older DB version, but the DB file isn't > meant for interchange so I don't see this as a problem. I think the concern was if/when the user changed to a different distro shipping a different libdb with an incompatible format. Say you are using distro X which has libdb4.5 and then you switch to distro Y which is using libdb4.4 and there are file format differences between 4.4 and 4.5, will Evolution successfully *downgrade* the db? Switching from 4.4 to 4.5 might work, but will 4.5 to 4.4? (note: this is a hypothetical, not sure if 4.4 and 4.5 have any file format differences at all) FWIW, it's been brought to my attention that Vista uses a directory (tree?) of vcard files for its user-global addressbook storage... perhaps this is a better approach than storing them in a berkeley db by default? Using a 1-vcard-per-file approach by default would make the berkeley db issue irrelevant. ..just something to consider. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Review a patch?
I just attached 2 alternative patches - "the-hard-way.patch" is similar to your patch but should fix the long param value problem the second patch is simpler in that it simply quotes all the values even if the value doesn't need to be quoted. Jeff On Thu, 2008-05-22 at 04:17 -0400, Michael B. Trausch wrote: > On Wed, 2008-05-21 at 20:24 -0400, Jeffrey Stedfast wrote: > > Fudging the linked list in camel is a gross hack (made worse by the > > fact that the MIME specification does not dictate that the name param > > be last), this is why I suggested you do it in the composer by making > > it set the name parameter last when constructing the headers. > > My intention was simply to have the most potential code benefit from the > patch, as opposed to localizing a fix in a client of the library. The > real benefit to the patch is that it will prevent users from assuming > (rationally, even though incorrectly) that there is a problem with > _their_ client, since other clients happen to work. > > I would love to just see the right thing get fixed here; that would of > course be the ideal solution. However, most users wouldn't be able to > fix this issue, and they'd give up and go back to what they know---that > which they *perceive* to be functional. Of course, if it's fixed in > just the composer, that gets around the immediate issue, but what > happens if some other piece of code uses EDS to build a message to be > sent to a buggy server? Am I missing something? > > Thanks, > Mike > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Review a patch?
Did you try your patch with any really long file names? Jeff On Thu, 2008-05-22 at 04:17 -0400, Michael B. Trausch wrote: > On Wed, 2008-05-21 at 20:24 -0400, Jeffrey Stedfast wrote: > > Fudging the linked list in camel is a gross hack (made worse by the > > fact that the MIME specification does not dictate that the name param > > be last), this is why I suggested you do it in the composer by making > > it set the name parameter last when constructing the headers. > > My intention was simply to have the most potential code benefit from the > patch, as opposed to localizing a fix in a client of the library. The > real benefit to the patch is that it will prevent users from assuming > (rationally, even though incorrectly) that there is a problem with > _their_ client, since other clients happen to work. > > I would love to just see the right thing get fixed here; that would of > course be the ideal solution. However, most users wouldn't be able to > fix this issue, and they'd give up and go back to what they know---that > which they *perceive* to be functional. Of course, if it's fixed in > just the composer, that gets around the immediate issue, but what > happens if some other piece of code uses EDS to build a message to be > sent to a buggy server? Am I missing something? > > Thanks, > Mike > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Review a patch?
Fudging the linked list in camel is a gross hack (made worse by the fact that the MIME specification does not dictate that the name param be last), this is why I suggested you do it in the composer by making it set the name parameter last when constructing the headers. Jeff On Wed, 2008-05-21 at 17:50 -0400, Michael B. Trausch wrote: > Some time ago, I submitted a patch to fix a bug in Evolution [1,2] that > is a simple workaround for some types of broken servers that don't > properly parse MIME header fields. > > The patch was rejected, however, I (still) do not understand why, and I > would like to do so such that I can get this patch into Evolution. I > can understand that it's not fun to work around server issues, but the > fix is not bad, and it maintains MIME standards compliance, without any > side effects that I have been able to note. I have been using this > patch personally since before I submitted it. > > Any advice or ideas? > > Thanks! > Mike Trausch > > [1] http://tinyurl.com/4ltg99 (Launchpad) > [2] http://bugzilla.gnome.org/show_bug.cgi?id=518312 > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution build fails on em-folder-properties.c
try rev 35503
On Fri, 2008-05-16 at 13:51 -0400, Reid Thompson wrote:
> ...
> AMEL_PROVIDERDIR=\"\" -DPREFIX=\"/opt/evo\" -DG_LOG_DOMAIN=\"evolution-mail\"
> -ggdb -O2 -march=prescott -g -Wall -Wmissing-prototypes -Wno-sign-compare -MT
> em-folder-properties.lo -MD -MP -MF .deps/em-folder-properties.Tpo -c
> ../../../evolution/mail/em-folder-properties.c -fPIC -DPIC -o
> .libs/em-folder-properties.o
> ../../../evolution/mail/em-folder-properties.c: In function 'emfp_commit':
> ../../../evolution/mail/em-folder-properties.c:101: warning: implicit
> declaration of function 'gtk_spin_button_get_value_as_int'
> ../../../evolution/mail/em-folder-properties.c:101: error: 'GtkSpinButton'
> undeclared (first use in this function)
> ../../../evolution/mail/em-folder-properties.c:101: error: (Each undeclared
> identifier is reported only once
> ../../../evolution/mail/em-folder-properties.c:101: error: for each function
> it appears in.)
> ../../../evolution/mail/em-folder-properties.c:101: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c:104: warning: implicit
> declaration of function 'gtk_spin_button_get_value'
> ../../../evolution/mail/em-folder-properties.c:104: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c: In function
> 'emfp_get_folder_item':
> ../../../evolution/mail/em-folder-properties.c:252: warning: implicit
> declaration of function 'gtk_spin_button_new_with_range'
> ../../../evolution/mail/em-folder-properties.c:252: warning: assignment makes
> pointer from integer without a cast
> ../../../evolution/mail/em-folder-properties.c:253: warning: implicit
> declaration of function 'gtk_spin_button_set_value'
> ../../../evolution/mail/em-folder-properties.c:253: error: 'GtkSpinButton'
> undeclared (first use in this function)
> ../../../evolution/mail/em-folder-properties.c:253: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c:254: warning: implicit
> declaration of function 'gtk_spin_button_set_numeric'
> ../../../evolution/mail/em-folder-properties.c:254: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c:255: warning: implicit
> declaration of function 'gtk_spin_button_set_digits'
> ../../../evolution/mail/em-folder-properties.c:255: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c:266: warning: assignment makes
> pointer from integer without a cast
> ../../../evolution/mail/em-folder-properties.c:267: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c:268: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c:269: error: expected
> expression before ')' token
> ../../../evolution/mail/em-folder-properties.c: In function
> 'emfp_dialog_got_folder_quota':
> ../../../evolution/mail/em-folder-properties.c:357: warning: assignment
> discards qualifiers from pointer target type
> ../../../evolution/mail/em-folder-properties.c:361: warning: assignment
> discards qualifiers from pointer target type
> make[5]: *** [em-folder-properties.lo] Error 1
> make[5]: *** Waiting for unfinished jobs
>
>
> last changes added these...
>
> [EMAIL PROTECTED] ~/evo-src/evolution/mail $ svn diff -r PREV
> em-folder-properties.c
> Index: em-folder-properties.c
> ===
> --- em-folder-properties.c (revision 35501)
> +++ em-folder-properties.c (working copy)
> @@ -97,6 +97,12 @@
> g_free (arg->ca_str);
> arg->ca_str = (char *) gtk_entry_get_text ((GtkEntry
> *) prop_data->widgets[i]);
> break;
> + case CAMEL_ARG_INT:
> + arg->ca_int = gtk_spin_button_get_value_as_int
> ((GtkSpinButton *) prop_data->widgets[i]);
> + break;
> + case CAMEL_ARG_DBL:
> + arg->ca_double = gtk_spin_button_get_value
> ((GtkSpinButton *) prop_data->widgets[i]);
> + break;
> default:
> g_warning ("This shouldn't be reached\n");
> break;
> @@ -237,6 +243,34 @@
> gtk_table_attach ((GtkTable *) table, w, 1, 2, row,
> row + 1, GTK_FILL | GTK_EXPAND, 0, 0, 0);
> prop_data->widgets[i] = w;
> break;
> + case CAMEL_ARG_INT:
> + label = gtk_label_new (prop->description);
> + gtk_misc_set_alignment ((GtkMisc *) label, 0.0, 0.5);
> + gtk_widget_show (label);
> + gtk_table_attach ((GtkTable *) table, label, 0, 1,
> row, row + 1, GTK_FILL, 0, 0, 0);
> +
> + w = gtk_spin_button_new_with
[Evolution-hackers] Camel Provider/Getv/Setv
I guess I've probably always been aware that there was some suckage here, but I never really knew how bad. So the other night I was trying to implement support for tweaking cache expiration preferences for IMAP4, but ran into some problems with providing a decent way of providing a UI for it. camel_object_[g,s]etv(): The problem with this method is that you can only specify a value type and a label. This makes it hard to present any sort of more complex user-input device for the user beyond true/false and possibly string input? (which is probably why CAMEL_ARG_BOO and CAMEL_ARG_STR were the only 2 arg-types mapped in the UI for folder properties). If you want to request a float or integer from the user, then you have no way of specifying an input range - nor do you have a proper way to represent the following UI: Cached messages should expire after [3600H] seconds. (e.g. text before and after the spinbutton, which helps to make the user-input query more readable) There's also no way to link inputs. For exmaple: [X] Expire messages older than [3600H] seconds. or [X] Enable XYZ XYZ should happen after [3600H] seconds. In the second example, the followup UI element should be disabled if the dependency element hasn't been enabled. I'm not sure which of the 2 above methods is the preferred choice (probably only 1 of them needs to be possible to do). camel-provider properties: Suffers from most of the same problems listed above. Not sure how exactly to fix these issues, but figured I'd maybe get the ball rolling by sending this mail and seeing if other people had ideas. The best I can come up with is some sort of XML blurb describing how the UI should look in some toolkit-agnostic way, but I'm not sure of the details. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] mboxtool
Not necessarily Evolution-specific, but I've had reason to 'fix' my
mailboxes a number of times in the past year and so I've written this
little tool.
gcc -o mboxtool mboxtool.c `pkg-config --cflags --libs gmime-2.0`
Enjoy.
Jeff
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: t; c-basic-offset: 8 -*- */
/*
* Authors: Jeffrey Stedfast <[EMAIL PROTECTED]>
*
* Copyright 2008 Novell, Inc. (www.novell.com)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Street #330, Boston, MA 02111-1307, USA.
*
*/
#ifdef HAVE_CONFIG_H
#include
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
enum {
RESORT = (1 << 0),
REMDUP = (1 << 1),
REUID = (1 << 2),
REPLACE = (1 << 3),
};
typedef struct {
char *msg_id;
off_t msg_start;
off_t msg_uid;
time_t msg_date;
char *msg_key;
int msg_dup;
} MsgInfo;
static int
datecmp (const void *a, const void *b)
{
MsgInfo *mia = (MsgInfo *) *((void **) a);
MsgInfo *mib = (MsgInfo *) *((void **) b);
return mia->msg_date - mib->msg_date;
}
static void
xev_cb (GMimeParser *parser, const char *header, const char *value, off_t offset, off_t *save)
{
*save = offset;
}
static int
sort_mbox (GMimeStream *istream, GMimeStream *ostream, GMimeStream *dstream, guint32 flags)
{
GHashTable *msgid_hash = NULL;
GMimeMessage *message;
GMimeStream *stream;
GMimeParser *parser;
GPtrArray *summary;
MsgInfo *info;
int tz_offset;
off_t offset;
char *from;
int rv = 0;
guint32 i;
if (flags & REMDUP)
msgid_hash = g_hash_table_new (g_str_hash, g_str_equal);
summary = g_ptr_array_new ();
parser = g_mime_parser_new ();
g_mime_parser_init_with_stream (parser, istream);
g_mime_parser_set_header_regex (parser, "^X-Evolution$", (GMimeParserHeaderRegexFunc) xev_cb, &offset);
g_mime_parser_set_scan_from (parser, TRUE);
while (!g_mime_parser_eos (parser)) {
offset = -1;
if (!(message = g_mime_parser_construct_message (parser)))
continue;
info = g_new (MsgInfo, 1);
info->msg_id = g_strdup (g_mime_message_get_message_id (message));
info->msg_start = g_mime_parser_get_from_offset (parser);
info->msg_uid = offset > info->msg_start ? (offset - info->msg_start) +
(summary->len > 0 ? 1 : 0) : -1;
g_mime_message_get_date (message, &info->msg_date, &tz_offset);
info->msg_date -= tz_offset;
info->msg_key = g_strdup_printf ("<%s>", info->msg_id);
info->msg_dup = (flags & REMDUP) && g_hash_table_lookup (msgid_hash, info->msg_key);
g_ptr_array_add (summary, info);
if ((flags & REMDUP) && !info->msg_dup)
g_hash_table_insert (msgid_hash, info->msg_key, info);
g_object_unref (message);
}
g_object_unref (parser);
if (msgid_hash != NULL)
g_hash_table_destroy (msgid_hash);
if (flags & RESORT)
qsort (summary->pdata, summary->len, sizeof (void *), datecmp);
for (i = 0; i < summary->len; i++) {
info = summary->pdata[i];
if ((rv = g_mime_stream_seek (istream, info->msg_start, GMIME_STREAM_SEEK_SET)) == -1)
break;
parser = g_mime_parser_new ();
g_mime_parser_init_with_stream (parser, istream);
g_mime_parser_set_scan_from (parser, TRUE);
message = g_mime_parser_construct_message (parser);
from = g_mime_parser_get_from (parser);
g_object_unref (parser);
if (info->msg_dup)
stream = dstream;
else
stream = ostream;
if (stream == NULL) {
g_free (from);
goto next;
}
offset = g_mime_stream_tell (stream);
if (offset > 0 && (rv = g_mime_stream_write (stream, "\n", 1)) == -1) {
g_object_unref (message);
g_free (from);
break;
}
if ((rv = g_mime_stream_write_string (stream, from)) == -1) {
g_object_unref (message);
g_free (from);
break;
}
g_free (from);
if ((rv = g_mime_stream_write (stream, "\n", 1)) == -1) {
g_object_unref (message);
break;
}
if ((rv = g_mime_object_write_to_stream ((GMimeObject *) message, stream)) == -1) {
g_object_unref (message);
break;
}
g_object_unref (message);
if ((flags & REUID) && offset != -1 && info->msg_uid != -1) {
if ((rv = g_mime_stream_seek (stream,
Re: [Evolution-hackers] Evolution doesnt recognise any mouse click events....PLZ HELP.......
honestly your best bet is probably to ask the Gtk+ developers, not us. Jeff On Fri, 2008-04-25 at 20:57 +0530, svalbard colaco wrote: > Hi all , > > just adding some more info to this... > > i get the followiing error > > [...] > > (evolution:3860): Gdk-DirectFB-WARNING **: > gdk_display_request_selection_notification Unimplemented function > > [...] > could this be the issue?? > does this help in debuggin the mentioned issueplz help > > Regards > sv.. > > > On Thu, Apr 24, 2008 at 8:59 PM, svalbard colaco > <[EMAIL PROTECTED]> wrote: > Hi all, > > Am porting Evolution Mail client with DFB > backendMy main window on start up does'nt > recognise any mouse click events > i.e. to say that when i click on File it shows the drop down > list but File/New/New mail mesaage does'nt recognise the mouse > click ; > whereas it recognises a key press (i.e. when a return key is > hit on it) and the corresponding child window gets > dispalyed.and the mouse click is recognised for all child > windows menus . > > > Why is this so?? Any idea??? plz help in this regard > > > Also some of the icons on the widget or buttons are dispalyed > as 'X'.plz help in this . > > Regards > sv. > > > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] SVN head build fails 'O_LARGEFILE' undeclared (first use in this function)
On Mon, 2008-04-07 at 16:22 -0400, Reid Thompson wrote: > explicitly passing --disable-largefile still yields an error... > should be fixed in rev 8626 Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Largefile support
On Mon, 2008-04-07 at 13:29 -0400, Matthew Barnes wrote: > On Mon, 2008-04-07 at 12:43 -0400, Jeffrey Stedfast wrote: > > The only 'gotcha' I can think of by enabling it by default is that it > > might break ABI if old builds were 32bit off_t's (the new off_t's would > > be 64bit). > > > > Oh, and fwiw, looking ahead, it may even be worth changing the public > > API to take goffset's rather than off_t's if breaking API is acceptable > > since it will prevent future off_t size issues (since I believe that > > goffset is supposed to be an int64_t) > > Yeah, and this would be the opportune time to do that if we're going to > (early in the development cycle). Sounds like we should wait to enable > largefile support by default until we do the goffset replacement, and > then ship both changes at once with a soname bump. sounds reasonable to me Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Largefile support
Oh, and fwiw, looking ahead, it may even be worth changing the public API to take goffset's rather than off_t's if breaking API is acceptable since it will prevent future off_t size issues (since I believe that goffset is supposed to be an int64_t) Jeff On Mon, 2008-04-07 at 12:35 -0400, Jeffrey Stedfast wrote: > I meant to keep it with the same defaults as before... did I goof? :( > > The only 'gotcha' I can think of by enabling it by default is that it > might break ABI if old builds were 32bit off_t's (the new off_t's would > be 64bit). > > I think the best coarse of action is to default it to the same off_t > size as before (which, even if the old behavior was to enable largefile, > since it was broken, might not have setup 64bit off_t's). > > Jeff > > On Mon, 2008-04-07 at 12:40 -0400, Matthew Barnes wrote: > > On Mon, 2008-04-07 at 17:11 +0100, [EMAIL PROTECTED] wrote: > > > Author: fejj > > > Date: Mon Apr 7 17:11:40 2008 > > > New Revision: 8625 > > > URL: http://svn.gnome.org/viewvc/evolution-data-server?rev=8625&view=rev > > > > > > Log: > > > 2008-04-07 Jeffrey Stedfast <[EMAIL PROTECTED]> > > > > > > * configure.in: Do proper checks for largefile support and > > > properly setup proper CFLAGS to support it. > > > > > > > Hey Jeff, > > > > Just curious why you chose to disable this by default. Seems like we'd > > want to take advantage of largefile support if it's available, or are > > there undesirable tradeoffs involved? > > > > Matthew Barnes > > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Largefile support
I meant to keep it with the same defaults as before... did I goof? :( The only 'gotcha' I can think of by enabling it by default is that it might break ABI if old builds were 32bit off_t's (the new off_t's would be 64bit). I think the best coarse of action is to default it to the same off_t size as before (which, even if the old behavior was to enable largefile, since it was broken, might not have setup 64bit off_t's). Jeff On Mon, 2008-04-07 at 12:40 -0400, Matthew Barnes wrote: > On Mon, 2008-04-07 at 17:11 +0100, [EMAIL PROTECTED] wrote: > > Author: fejj > > Date: Mon Apr 7 17:11:40 2008 > > New Revision: 8625 > > URL: http://svn.gnome.org/viewvc/evolution-data-server?rev=8625&view=rev > > > > Log: > > 2008-04-07 Jeffrey Stedfast <[EMAIL PROTECTED]> > > > > * configure.in: Do proper checks for largefile support and > > properly setup proper CFLAGS to support it. > > > > Hey Jeff, > > Just curious why you chose to disable this by default. Seems like we'd > want to take advantage of largefile support if it's available, or are > there undesirable tradeoffs involved? > > Matthew Barnes > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A relatively simple Evolution IMAP-code task, that improves memory consumption
yea, this would be a good task for someone new to the code if anyone is up for learning a bit about Camel internals. Jeff On Mon, 2008-04-07 at 14:50 +0200, Philip Van Hoof wrote: > Hi there, hackers. > > While appending a message to an IMAP folder, Evolution consumes the > entire message into memory. > > At the Tinymail project (which is a lib that uses a modified Camel) we > are not planning to rewrite this right now: it's not blocking any of the > Modest bugs (Modest is an E-mail client using Tinymail). Right now a > stable release for Modest has a priority over implementing new features > that promise better memory usage. > > It's however trivial to implement this one. I added comments how to do > it to Tinymail's camel-lite's camel-imap-folder.c > > http://tinymail.org/trac/tinymail/changeset/3554 > > If somebody is interested in this, I think it's a nice contribution, > very localised in scope (it's just this function) and good way to get > your hands dirty on Evolution's IMAP code. Being code addicts, we all > love to get our hands dirty, right? > > The function is unmodified in Tinymail's camel-lite (other than the > comment). Your patch would, after being tested, go downstream into > Tinymail too. Of course. > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm
On Sun, 2008-01-27 at 13:44 +0100, Philip Van Hoof wrote: > This is very strange, though. It looks like stream=0x0 but the > mime-parser's stream ain't NULL. that just means the stream the parser is using is not a subclass of CamelSeekableSubstream Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm
Something like the attached patch might work, tho it is untested.
If this doesn't work, then I suspect the problem is that the seek
position might get changed out from under the mime parser (assuming it
is using either a CamelStreamFs or an fd).
Note that camel_stream_fs_new_with_fd[_and_bounds]() calls lseek() on
the fd passed in.
>From the dup() man page:
After a successful return from dup() or dup2(), the old and new file
descriptors may be used interchangeably. They refer to the same open
file description (see open(2)) and thus share file offset and file sta‐
tus flags; for example, if the file offset is modified by using
lseek(2) on one of the descriptors, the offset is also changed for the
other.
So my guess is that this will break the parser :(
It might break in the stream case as well, you'd have to follow the code
paths a bit to know for sure. For instance, even if creating the
seekable substream doesn't perform an underlying seek on the original
stream, setting it in a data wrapper might call camel_stream_reset()
which /might/ do an lseek() on the source fs stream.
Not an insurmountable problem to solve, but it does make things a little
more difficult and possibly touchy.
Jeff
On Sat, 2008-01-26 at 22:48 -0500, Jeffrey Stedfast wrote:
> On Sat, 2008-01-26 at 22:12 -0500, Jeffrey Stedfast wrote:
> > On Sat, 2008-01-26 at 13:44 +0100, Philip Van Hoof wrote:
> > > This is what happens if you try to open a truly large E-mail on a device
> > > that has not as much memory available:
> > >
> > > Is there something we can do about this? Can we change the MIME parsing
> > > algorithm to be less memory demanding for example?
> > >
> > > Note that GArray is not really very sparse with memory once you start
> > > having a really large array. Perhaps we can in stead change this to a
> > > normal pointer array of a fixed size (do we know the size before we
> > > start parsing, so that we can allocate an exact size in stead, perhaps?)
> >
> > eh, why would you change it to a GPtrArray? It doesn't hold pointers, it
> > holds message part content.
> >
> > Unfortunately we don't know the size ahead of time.
> >
> > I suppose you could use a custom byte array allocator so that you can
> > force it to grow by larger chunks or something, dunno.
> >
> >
> > The way GMime handles this is by not loading content into RAM, but
> > that may be harder to do with Camel, especially in the mbox case.
>
> er, I should probably explain this:
>
> - writing the code should be relatively easy to do, but in the mbox
> case, the mbox may end up getting expunged or rewritten for some other
> reason which may cause problems, not sure how that would work.
>
> I think in Maildir, as long as the fd remains open, the file won't
> actually disappear after an unlink() until the fd gets closed, so that
> might work out ok assuming you can spare the fd (which might be the
> other problem with Evolution?).
>
> Jeff
>
>
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
Index: ChangeLog
===
--- ChangeLog (revision 8425)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2008-01-26 Jeffrey Stedfast <[EMAIL PROTECTED]>
+
+ * camel-mime-part-utils.c (simple_data_wrapper_construct_from_parser):
+ If possible, keep the content on disk.
+
2008-01-24 Matthew Barnes <[EMAIL PROTECTED]>
* camel-object.c (camel_object_cast):
Index: camel-mime-part-utils.c
===
--- camel-mime-part-utils.c (revision 8425)
+++ camel-mime-part-utils.c (working copy)
@@ -57,25 +57,47 @@
static void
simple_data_wrapper_construct_from_parser (CamelDataWrapper *dw, CamelMimeParser *mp)
{
+ GByteArray *buffer = NULL;
+ CamelStream *stream;
+ off_t start, end;
+ int fd = -1;
+ size_t len;
char *buf;
- GByteArray *buffer;
- CamelStream *mem;
- size_t len;
-
+
d(printf ("simple_data_wrapper_construct_from_parser()\n"));
-
- /* read in the entire content */
- buffer = g_byte_array_new ();
+
+ if (!(stream = camel_mime_parser_stream (mp)))
+ fd = camel_mime_parser_fd (mp);
+ else if (!CAMEL_IS_SEEKABLE_SUBSTREAM (stream))
+ stream = NULL;
+
+ if ((stream || fd != -1) && (start = camel_mime_parser_tell (mp)) != -1) {
+ /* we can keep content on disk */
+ } else {
+ /* need to load content into memory */
+ buffer = g_byte_array_new ();
+ }
+
while (camel_mime_parser_step (mp, &buf, &len) != CAMEL_MIME_PARSER_STATE_BODY_END) {
- d(printf(&qu
Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm
On Sat, 2008-01-26 at 22:12 -0500, Jeffrey Stedfast wrote: > On Sat, 2008-01-26 at 13:44 +0100, Philip Van Hoof wrote: > > This is what happens if you try to open a truly large E-mail on a device > > that has not as much memory available: > > > > Is there something we can do about this? Can we change the MIME parsing > > algorithm to be less memory demanding for example? > > > > Note that GArray is not really very sparse with memory once you start > > having a really large array. Perhaps we can in stead change this to a > > normal pointer array of a fixed size (do we know the size before we > > start parsing, so that we can allocate an exact size in stead, perhaps?) > > eh, why would you change it to a GPtrArray? It doesn't hold pointers, it > holds message part content. > > Unfortunately we don't know the size ahead of time. > > I suppose you could use a custom byte array allocator so that you can > force it to grow by larger chunks or something, dunno. > > > The way GMime handles this is by not loading content into RAM, but > that may be harder to do with Camel, especially in the mbox case. er, I should probably explain this: - writing the code should be relatively easy to do, but in the mbox case, the mbox may end up getting expunged or rewritten for some other reason which may cause problems, not sure how that would work. I think in Maildir, as long as the fd remains open, the file won't actually disappear after an unlink() until the fd gets closed, so that might work out ok assuming you can spare the fd (which might be the other problem with Evolution?). Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm
On Sat, 2008-01-26 at 13:44 +0100, Philip Van Hoof wrote: > This is what happens if you try to open a truly large E-mail on a device > that has not as much memory available: > > Is there something we can do about this? Can we change the MIME parsing > algorithm to be less memory demanding for example? > > Note that GArray is not really very sparse with memory once you start > having a really large array. Perhaps we can in stead change this to a > normal pointer array of a fixed size (do we know the size before we > start parsing, so that we can allocate an exact size in stead, perhaps?) eh, why would you change it to a GPtrArray? It doesn't hold pointers, it holds message part content. Unfortunately we don't know the size ahead of time. I suppose you could use a custom byte array allocator so that you can force it to grow by larger chunks or something, dunno. The way GMime handles this is by not loading content into RAM, but that may be harder to do with Camel, especially in the mbox case. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Diary replaying on IMAP accounts
On Mon, 2008-01-21 at 13:17 +0100, Philip Van Hoof wrote: > On Sat, 2008-01-19 at 10:48 -0500, Jeffrey Stedfast wrote: > > This is why I started looking at dropping CamelDisco* and replacing all > > instances with CamelOffline* - tri-state is awful, dual-state is ftw. > > > > anyways, if your fix works, go for it. > > Hey Jeffrey, > > Do you think that this should be committed in upstream Camel too? > > I'll pass the question to Matthew too. I'm not sure whether the function > should indeed always return TRUE in case of RESYNCING state. Perhaps > it's better to adapt the return value of the function and replace all > uses of it? Perhaps TRUE in case of RESYNCING is fine? > > There are indeed multiple solutions to solve this. > > Note that once the diary starts working, you'll have one or two small > bugs in the diary code too (a variable diary->folders becoming NULL at > some point, yet still being used somewhere). > > I wonder whether these diaries ever worked? So suddenly making it work > might introduce new bugs in Evolution too. > > Note that the behaviour is that the APPEND command will fail, Camel will > react to that failure by reconnecting and forgetting about the diary. > > The result can be called data loss .. since the message that was to be > appended is now only locally available, and not appended remotely. > > It's kinda hard to spot this bug, as it requires working with another > E-mail client (if you open the message, it'll just work since it's > cached locally, and it'll also be in the summary since the summary > supports temporary UIDs). > > (sounds like severe to me) > To be honest, I have no idea what the side effects of changing that code to return TRUE for the RESYNCING state are. That's one of the problems with a tri-state that isn't really a tri-state :\ As you mentioned, having it return FALSE is clearly not "correct" and returning TRUE may introduce some bugs :\ As far as I know, there are some bugs regarding offline usage not resyncing properly when going back online, so you may have found the cause. I'll let the current maintainers make a judgment call on whether to accept this into mainline Camel or not (looks like either way, there's gonna have to be some attention given to this area of code) Sorry that I can't be any more "concrete" than that :( Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Diary replaying on IMAP accounts
This is why I started looking at dropping CamelDisco* and replacing all
instances with CamelOffline* - tri-state is awful, dual-state is ftw.
anyways, if your fix works, go for it.
Jeff
On Sat, 2008-01-19 at 15:13 +0100, Philip Van Hoof wrote:
> Hi there,
>
> When we connect with an IMAP service if we have moved messages while we
> where offline, the diary's replay function will be utilised.
>
> While this takes place, the store's disco connection state is
> CAMEL_DISCO_STORE_RESYNCING.
>
> The camel_disco_store_check_online seems to only care about this state
> being ONLINE. RESYNCING is not seen as being online. It seems that
> therefore commands like the APPEND one are failing:
>
>
> void
> camel_disco_diary_replay (CamelDiscoDiary *diary, CamelException *ex)
> {
> ...
> camel_folder_append (...)
> ... or ...
> camel_folder_transfer_messages_to (...)
> ...
> }
>
>
> imap_append_online (CamelFolder *folder, CamelMimeMessage *message,
> const CamelMessageInfo *info, char **appended_uid,
> CamelException *ex)
> {
> ...
> do_append (...)
> ...
> }
>
> static CamelImapResponse *
> do_append (CamelFolder *folder, CamelMimeMessage *message,
> const CamelMessageInfo *info, char **uid,
> CamelException *ex)
> {
> ...
> response = camel_imap_command (store, NULL, ex, "APPEND %F%s%s {%d}",
> folder->full_name, flagstr ? " " : "",
> flagstr ? flagstr : "", ba->len);
> g_free (flagstr);
>
> if (!response) {
> ...
> retry ... (but eventually)
> return NULL;
> ...
> }
>
> ...
> }
>
>
> CamelImapResponse *
> imap_read_response (CamelImapStore *store, CamelException *ex)
> {
> ...
> response->untagged = g_ptr_array_new ();
> while ((type = camel_imap_command_response (store, &respbuf, ex))
> == CAMEL_IMAP_RESPONSE_UNTAGGED)
> g_ptr_array_add (response->untagged, respbuf);
>
> if (type == CAMEL_IMAP_RESPONSE_ERROR) {
> camel_imap_response_free_without_processing (store, response);
> > return NULL; <-
> }
> ...
> }
>
>
> CamelImapResponseType
> camel_imap_command_response (CamelImapStore *store, char **response,
>CamelException *ex)
> {
> CamelImapResponseType type;
> char *respbuf;
> int len = -1;
>
> if (camel_imap_store_readline (store, &respbuf, ex) < 0) {
> CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
> ---> return CAMEL_IMAP_RESPONSE_ERROR; <--- this happens
> }
>
> ...
> }
>
>
> /* FIXME: please god, when will the hurting stop? Thus function is so
>fucking broken it's not even funny. */
> ssize_t
> camel_imap_store_readline (CamelImapStore *store, char **dest, CamelException
> *ex)
> {
> CamelStreamBuffer *stream;
> char linebuf[1024] = {0};
> GByteArray *ba;
> ssize_t nread;
>
> g_return_val_if_fail (CAMEL_IS_IMAP_STORE (store), -1);
> g_return_val_if_fail (dest, -1);
>
> *dest = NULL;
>
> /* Check for connectedness. Failed (or cancelled) operations will
> * close the connection. We can't expect a read to have any
> * meaning if we reconnect, so always set an exception.
> */
>
> if (!camel_imap_store_connected (store, ex))
> ->>return -1; <---
>
> ...
> }
>
>
> gboolean
> camel_imap_store_connected (CamelImapStore *store, CamelException *ex)
> {
> ... (lot's of completely funny looking code, but eventually): ...
> camel_disco_store_check_online
> ...
> }
>
> gboolean
> camel_disco_store_check_online (CamelDiscoStore *store, CamelException *ex)
> {
> --> Nothing here seems to accept the RESYNCING state as being online
> <---
>
> if (camel_disco_store_status (store) != CAMEL_DISCO_STORE_ONLINE) {
> camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
> _("You must be working online to "
>"complete this operation"));
> return FALSE;
> }
>
> return TRUE;
> }
>
>
>
> note: I have fixed this in my version by doing this:
>
>
> gboolean
> camel_disco_store_check_online (CamelDiscoStore *store, CamelException *ex)
> {
>
> if (camel_disco_store_status (store) == CAMEL_DISCO_STORE_RESYNCING)
> return TRUE;
>
> if (camel_disco_store_status (store) != CAMEL_DISCO_STORE_ONLINE) {
> camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
>_("You must be working online to "
> "complete this operation"));
> return FAL
Re: [Evolution-hackers] Build failure in evo: need a lot of stuff!
On Fri, 2008-01-18 at 16:32 -0500, Paul Smith wrote: > Hi all; > > I'm getting a build failure in Evo and gtkhtml with the latest glib: > editor-control-factory.c: In function 'editor_get_prop': > editor-control-factory.c:463: error: expected expression before 'do' > Apparently, the latest glib broke the libbonobo from Gnome 2.20, so if > you install the latest glib you also need the latest libbonobo. you might want to warn the glib guys about this then... seems they have broken API or ABI which is a strict no-no. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improved rfc2047 decode patch
83AD: header_decode_address (camel-mime-utils.c:2727) > ==32055==by 0x50589FB: camel_header_address_decode > (camel-mime-utils.c:2997) > ==32055==by 0x5043A26: internet_decode (camel-internet-address.c:91) > ==32055==by 0x5039789: camel_address_decode (camel-address.c:129) > ==32055==by 0x504E71A: process_header (camel-mime-message.c:708) > ==32055==by 0x504E851: add_header (camel-mime-message.c:745) > ==32055==by 0x504585C: camel_medium_add_header (camel-medium.c:145) > ==32055==by 0x50533FB: construct_from_parser (camel-mime-part.c:963) > ==32055==by 0x504E317: construct_from_parser (camel-mime-message.c:597) > ==32055==by 0x50534DA: camel_mime_part_construct_from_parser > (camel-mime-part.c:995) > > > > On Thu, 2007-12-27 at 08:25 -0500, Jeffrey Stedfast wrote: > > On Thu, 2007-12-27 at 08:46 +0800, jacky wrote: > > > --- Jeffrey Stedfast <[EMAIL PROTECTED]>wrote: > > > > > > > > > > > On Thu, 2007-12-27 at 00:20 +0800, jacky wrote: > > > > > It seem that your patch don't support this kind of > > > > > encoded string: > > > > > > > > > > > > =?gb2312?b? > > > > Two encoded-words are not separated by any > > > > character. > > > > > > > > Are you sure? I wrote the code to be able to handle > > > > this case and I just > > > > tested it again (noticed that I didn't have a test > > > > case like this in my > > > > test suite so added one) and it works fine. > > > > > > > > Do you have an example subject/whatever header for > > > > me to test against? > > > > > > > > > > I make my conclusion too hastiness. Yes, your patch > > > support this kind of email, > > > > ok ;-) > > > > > but it didn't support the > > > email that break a single multi-byte character across > > > multiple encoded-word tokens, and when it decode the > > > header that break a encoded-word token across two > > > lines, there is no result display on evolution, for > > > example, the Subject is empty. > > > > ok, just fixed this in svn. I had tested a broken UTF-8 header earlier > > and so didn't see a slight bug in my code. > > > > > I'll use Camle with your patch to check all email on > > > my mbox and use gmime to decode all email header to > > > find out it's capacity. > > > > > > Ok, awesome. > > > > Jeff > > > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improved rfc2047 decode patch
On Thu, 2007-12-27 at 08:46 +0800, jacky wrote: > --- Jeffrey Stedfast <[EMAIL PROTECTED]>wrote: > > > > > On Thu, 2007-12-27 at 00:20 +0800, jacky wrote: > > > It seem that your patch don't support this kind of > > > encoded string: > > > > > > =?gb2312?b? > > Two encoded-words are not separated by any > > character. > > > > Are you sure? I wrote the code to be able to handle > > this case and I just > > tested it again (noticed that I didn't have a test > > case like this in my > > test suite so added one) and it works fine. > > > > Do you have an example subject/whatever header for > > me to test against? > > > > I make my conclusion too hastiness. Yes, your patch > support this kind of email, ok ;-) > but it didn't support the > email that break a single multi-byte character across > multiple encoded-word tokens, and when it decode the > header that break a encoded-word token across two > lines, there is no result display on evolution, for > example, the Subject is empty. ok, just fixed this in svn. I had tested a broken UTF-8 header earlier and so didn't see a slight bug in my code. > I'll use Camle with your patch to check all email on > my mbox and use gmime to decode all email header to > find out it's capacity. Ok, awesome. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improved rfc2047 decode patch
On Thu, 2007-12-27 at 00:20 +0800, jacky wrote: > It seem that your patch don't support this kind of > encoded string: > =?gb2312?b? Two encoded-words are not separated by any character. Are you sure? I wrote the code to be able to handle this case and I just tested it again (noticed that I didn't have a test case like this in my test suite so added one) and it works fine. Do you have an example subject/whatever header for me to test against? Jeff > > --- Jeffrey Stedfast <[EMAIL PROTECTED]>wrote: > > > This patch is a port of my GMime rfc2047 decoder > > which is even more > > liberal in what it accepts than Thunderbird and is > > what I will be > > committing to svn. > > > > closing bugs: > > > > #302991 > > #315513 > > #502178 > > > > Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improved rfc2047 decode patch
I noticed that the while (camel_mime_is_dtext(*inptr) && *inptr) got reversed in your camel-lite patch, which must mean that you had locally changed the code to do the *inptr check first... I think your change was correct, we should be checking *inptr first before passing it to camel_mime_is_dtext(), so I've made that change to upstream camel. it likely won't make a difference, but it saves a few instructions by avoiding an unnecessary lookup (*inptr can't be valid dtext if *inptr is nul) Also, you'll want to update camel-charset-map-private.h in your camel-lite branch or the update to camel-charset-map.c doesn't actually get you anything (that change is really only for auto-generating camel-charset-map-private.h) Which reminds me... I need to commit jacky's e-iconv change as well. Jeff On Wed, 2007-12-26 at 01:41 +0100, Philip Van Hoof wrote: > Awesome! In the afternoon I started with the exact same port, but had to > pause because of "family visiting", I'm back home and you have it > finished :). Thanks a lot! > > Brought it to tny's camel. FYI: > http://tinymail.org/trac/tinymail/changeset/3203 > > > On Tue, 2007-12-25 at 19:28 -0500, Jeffrey Stedfast wrote: > > This patch is a port of my GMime rfc2047 decoder which is even more > > liberal in what it accepts than Thunderbird and is what I will be > > committing to svn. > > > > closing bugs: > > > > #302991 > > #315513 > > #502178 > > > > Jeff > > > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] improved rfc2047 decode patch
This patch is a port of my GMime rfc2047 decoder which is even more
liberal in what it accepts than Thunderbird and is what I will be
committing to svn.
closing bugs:
#302991
#315513
#502178
Jeff
Index: camel-mime-utils.c
===
--- camel-mime-utils.c (revision 8315)
+++ camel-mime-utils.c (working copy)
@@ -821,116 +821,321 @@
*in = inptr;
}
-/* decode rfc 2047 encoded string segment */
static char *
-rfc2047_decode_word(const char *in, size_t len)
+camel_iconv_strndup (iconv_t cd, const char *string, size_t n)
{
- const char *inptr = in+2;
- const char *inend = in+len-2;
+ size_t inleft, outleft, converted = 0;
+ char *out, *outbuf;
const char *inbuf;
- const char *charset;
- char *encname, *p;
- int tmplen;
- size_t ret;
- char *decword = NULL;
- char *decoded = NULL;
- char *outbase = NULL;
- char *outbuf;
- size_t inlen, outlen;
- gboolean retried = FALSE;
- iconv_t ic;
-
- d(printf("rfc2047: decoding '%.*s'\n", len, in));
-
- /* quick check to see if this could possibly be a real encoded word */
- if (len < 8 || !(in[0] == '=' && in[1] == '?' && in[len-1] == '=' && in[len-2] == '?')) {
- d(printf("invalid\n"));
- return NULL;
- }
-
- /* skip past the charset to the encoding type */
- inptr = memchr (inptr, '?', inend-inptr);
- if (inptr != NULL && inptr < inend + 2 && inptr[2] == '?') {
- d(printf("found ?, encoding is '%c'\n", inptr[0]));
- inptr++;
- tmplen = inend-inptr-2;
- decword = g_alloca (tmplen); /* this will always be more-than-enough room */
- switch(toupper(inptr[0])) {
- case 'Q':
- inlen = quoted_decode((const unsigned char *) inptr+2, tmplen, (unsigned char *) decword);
- break;
- case 'B': {
- int state = 0;
- unsigned int save = 0;
-
- inlen = camel_base64_decode_step((unsigned char *) inptr+2, tmplen, (unsigned char *) decword, &state, &save);
- /* if state != 0 then error? */
- break;
+ size_t outlen;
+ int errnosav;
+
+ if (cd == (iconv_t) -1)
+ return g_strndup (string, n);
+
+ outlen = n * 2 + 16;
+ out = g_malloc (outlen + 4);
+
+ inbuf = string;
+ inleft = n;
+
+ do {
+ errno = 0;
+ outbuf = out + converted;
+ outleft = outlen - converted;
+
+ converted = iconv (cd, (char **) &inbuf, &inleft, &outbuf, &outleft);
+ if (converted == (size_t) -1) {
+ if (errno != E2BIG && errno != EINVAL)
+goto fail;
}
- default:
- /* uhhh, unknown encoding type - probably an invalid encoded word string */
- return NULL;
+
+ /*
+ * E2BIG There is not sufficient room at *outbuf.
+ *
+ * We just need to grow our outbuffer and try again.
+ */
+
+ converted = outbuf - out;
+ if (errno == E2BIG) {
+ outlen += inleft * 2 + 16;
+ out = g_realloc (out, outlen + 4);
+ outbuf = out + converted;
}
- d(printf("The encoded length = %d\n", inlen));
- if (inlen > 0) {
- /* yuck, all this snot is to setup iconv! */
- tmplen = inptr - in - 3;
- encname = g_alloca (tmplen + 1);
- memcpy (encname, in + 2, tmplen);
- encname[tmplen] = '\0';
+ } while (errno == E2BIG && inleft > 0);
+
+ /*
+ * EINVAL An incomplete multibyte sequence has been encoun
+ * tered in the input.
+ *
+ * We'll just have to ignore it...
+ */
+
+ /* flush the iconv conversion */
+ iconv (cd, NULL, NULL, &outbuf, &outleft);
+
+ /* Note: not all charsets can be nul-terminated with a single
+ nul byte. UCS2, for example, needs 2 nul bytes and UCS4
+ needs 4. I hope that 4 nul bytes is enough to terminate all
+ multibyte charsets? */
+
+ /* nul-terminate the string */
+ memset (outbuf, 0, 4);
+
+ /* reset the cd */
+ iconv (cd, NULL, NULL, NULL, NULL);
+
+ return out;
+
+ fail:
+
+ errnosav = errno;
+
+ w(g_warning ("camel_iconv_strndup: %s at byte %lu", strerror (errno), n - inleft));
+
+ g_free (out);
+
+ /* reset the cd */
+ iconv (cd, NULL, NULL, NULL, NULL);
+
+ errno = errnosav;
+
+ return NULL;
+}
- /* rfc2231 updates rfc2047 encoded words...
- * The ABNF given in RFC 2047 for encoded-words is:
- * encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
- * This specification changes this ABNF to:
- * encoded-word := "=?" charset ["*" language] "?" encoding "?" encoded-text "?="
- */
+#define is_ascii(c) isascii ((int) ((unsigned char) (c)))
- /* trim off the 'language' part if it's there... */
- p = strchr (encname, '*');
- if (p)
-*p = '\0';
-
- charset = e_iconv_charset_name (encname);
-
- inbuf = decword;
-
- outlen = inlen * 6 + 16;
- outbase = g_alloca (outlen);
- outbuf = outbase;
-
- retry:
- ic = e_iconv_open ("UTF-8", charset);
- if (ic != (iconv_t) -1) {
-ret = e_iconv (ic, &inbuf, &inlen, &outbuf, &outlen);
-if (ret != (size_t) -1) {
- e_iconv (ic, NULL, 0, &outbuf, &outlen);
- *outbuf = 0;
- decoded = g_strdup (outbase);
+static char *
+decode_8bit (const char *text, size_t len, const char *default_charset)
+{
+ const char *charsets[
Re: [Evolution-hackers] [patch] fixed incorrect rfc2047 decode for CJK header
FWIW, even Thunderbird doesn't handle multi-byte characters split across multiple encoded-word tokens. I was just checking out their implementation in mozilla/netwerk/src/nsMIMEHeaderParamImpl.cpp:DecodeRFC2047Str() Jeff On Sun, 2007-12-23 at 23:09 +0800, jacky wrote: > Hi, all. > > The rfc2047 decoder in libcamel can not decode some > CJK header correctly. Although some of them are not > correspond to RFC, but I need to decode it correctly > and I thought if evolution can display there email > correctly more people like it. > > So I write a new rfc2047 decoder, and it's in the > patch. With the patch, libcamel can decode CJK header > correctly and evolution can display CJK header > correctly now. I had test it in my mailbox. My mailbox > has 2000 emails which were sent by evolution, > thunderbird, outlook, outlook express, foxmail, open > webmail, yahoo, gmail, lotus notes, etc. Without this > patch, almost 20% of there emails can't be decoded and > displayed correctly, with this patch, 99% of there > emails can be decoded and displayed correctly. > > And I found that the attachment with CJK name can't be > recognised and displayed by outlook / outlook express > / foxmail. This is because there email clients do not > support RFC2184. Evolution always use RFC2184 encode > mothod to encode attachment name, so the email with > CJK named attachment can't display in outlook / > outlook express / foxmail. In thunderbird, you can set > the option "mail.strictly_mime.parm_folding" to 0 or 1 > for using RFC2047 encode mothod to encode attachment > name. Can we add a similar option? > > Best regards. > > > ___ > 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ > http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline > ___ Evolution-hackers mailing > list Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [patch] fixed incorrect rfc2047 decode for CJKheader
On Tue, 2007-12-25 at 15:56 +0800, jacky wrote: > But the problem describe below has not been solved. > > 1) An encoded-word was divided into two line. This > was > > sent by dotProject v2.0.1 . > > As I seen this kind of email use quoted encode only, > and header_decode_text() can get all encoded-words > which is separated by SPACE, a simple solution is > replace SPACE with '_'. In fact OpenWebmail do like > this. > But the problem is I must change the prototype of > header_decode_text() to > char *header_decode_text (char *in, size_t inlen, int > ctext, const char *default_charset) > Originality, it is > char *header_decode_text (const char *in, size_t > inlen, int ctext, const char *default_charset) > Functions which call header_decode_text() must been > changed too. > Does anyone have better proposal? It would be a bad idea to have header_decode_text() modify the original string. I highly suggest starting with GMime's g_mime_utils_header_decode_text() implementation because it handles all the problems you've described. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [patch] fixed incorrect rfc2047 decode for CJK header
Hi Jacky, I've looked over your patch, but unfortunately it is unusable. The patch is riddled with buffer overflows and incorrect logic. What types of bugs are you actually trying to fix? What is it about CJK messages in particular that are not getting decoded properly? Your email was overly vague. Your changes to e-iconv can probably be taken if I understand correctly that GBK is a superset of gb2312 ( http://en.wikipedia.org/wiki/GBK ), altho it would have been nice to have gotten some sort of link explaining that with your original email (or via a ChangeLog entry) :) Thanks, Jeff On Sun, 2007-12-23 at 23:09 +0800, jacky wrote: > Hi, all. > > The rfc2047 decoder in libcamel can not decode some > CJK header correctly. Although some of them are not > correspond to RFC, but I need to decode it correctly > and I thought if evolution can display there email > correctly more people like it. > > So I write a new rfc2047 decoder, and it's in the > patch. With the patch, libcamel can decode CJK header > correctly and evolution can display CJK header > correctly now. I had test it in my mailbox. My mailbox > has 2000 emails which were sent by evolution, > thunderbird, outlook, outlook express, foxmail, open > webmail, yahoo, gmail, lotus notes, etc. Without this > patch, almost 20% of there emails can't be decoded and > displayed correctly, with this patch, 99% of there > emails can be decoded and displayed correctly. > > And I found that the attachment with CJK name can't be > recognised and displayed by outlook / outlook express > / foxmail. This is because there email clients do not > support RFC2184. Evolution always use RFC2184 encode > mothod to encode attachment name, so the email with > CJK named attachment can't display in outlook / > outlook express / foxmail. In thunderbird, you can set > the option "mail.strictly_mime.parm_folding" to 0 or 1 > for using RFC2047 encode mothod to encode attachment > name. Can we add a similar option? > > Best regards. > > > ___ > 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ > http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline > ___ Evolution-hackers mailing > list Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] More on message state
$Label[1-5] are the same user-flag names that Thunderbird uses for those colours Flag-for-followup is a copy of the Outlook feature and likely cannot be simply mapped to some "ToDo" flag (never even heard of that flag). Internally, these are represented in the CamelTag list on the CamelMessageInfo's. My suggestion would be to find out how Outlook stores this state info on an IMAP server and to copy its way of doing it. Jeff On Fri, 2007-11-30 at 09:49 -0800, Ross Boylan wrote: > After poking around, I discovered that although "follow up" status is > not preserved on copy, and is not kept on the IMAP server even where it > exists, the colored labels are preserved on copy and are kept on the > IMAP server (as $Label1, etc). > > So I think I have a solution to my immediate problem: > 1) get all messages marked for followup together (e.g., by sorting or > vfolder). > 2) select them all > 3) right click | label | ToDo. > 4) copy the folder. > > If I look at the folder from different evo clients, they should all show > the ToDo status (whereas the "FollowUp" status is kept with the client). > > There do seem to more types of message status, and more ways of handling > them internally, then necessary. I think the situation is this > > Replied, seen, and other "standard" IMAP status information is kept in a > bit mask in a single word and stored in the standard IMAP flags. These > are copied. > > "Labels" that affect coloring (e.g., To Do) are kept in a special info > structure, and stored on the IMAP server in custom flags $Label1, 2, > etc. (It might be better to use flags with meaningful names, though > that does increase the risk of clashingn with other uses of those names. > On the other hand, another app that sets a ToDo flag prbably means the > same thing as evolution does). These are copied. > > "Mark for followup" and its attendent substates--I'm not sure how this > is handled internally, though it may be the string-valued user tags. It > is not kept on the IMAP server, and is not copied. > > Ross > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] How does evo find its components? (switching installs of evo)
On Mon, 2007-10-29 at 15:45 -0400, Paul Smith wrote: > On Fri, 12 Oct 2007 16:37:06 -0700, Matthew Barnes wrote: > > On Fri, 2007-10-12 at 13:17 -0400, Paul Smith wrote: > > > How does Evolution decide where to get e-d-s, plugins, etc.? How can I > > > reset it to run the ones in /usr/bin and ignore the stuff in /opt/evo? > > > I don't remember doing anything special to switch it over to /opt/evo in > > > the first place. > > > > You can control it with environment variables: > > > > LD_LIBRARY_PATH=/opt/evo/lib > >Overrides the search path for dynamically loaded libraries. > > > > BONOBO_ACTIVATION_PATH=/opt/evo/lib/bonobo/servers > >Overrides the search path for Bonobo servers. > > Hm, this doesn't seem to help for me. I now have the opposite problem. > On my work system I reinstalled from Ubuntu 7.10 scratch (because I > wanted to repartition my disk to have a separate /home partition). > > I started Evolution from /usr/bin and it worked OK. Then I decided I > wanted to run with a version I had built myself from SVN, and > compiled/installed it into /opt/evo. > > I have a shell script I'm running to start Evo, and it sets up my > environment then logs all kinds of details, so I know my environment is > correct; here's an excerpt from the log (obtained by running "env | > sort" so I know these are properly exported as well): > > BONOBO_ACTIVATION_PATH=/opt/evo/lib/bonobo/servers > LD_LIBRARY_PATH=/opt/evo/lib/evolution/2.12:/opt/evo/lib > > PATH=/opt/evo/libexec/evolution/2.12:/opt/evo/libexec:/opt/evo/bin:/home/psmith/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/games > Evolution start on Mon Oct 29 15:35:55 EDT 2007: > '/opt/evo/bin/evolution' > > But when I use ps to see what's running, I get: > > $ ps -aef | grep evo > psmith1512 7673 6 15:40 pts/500:00:01 /opt/evo/bin/evolution > psmith1526 1 0 15:40 ?00:00:00 > /usr/lib/evolution/evolution-data-server-1.12 > --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck > --oaf-ior-fd=25 > psmith1546 1 3 15:40 ?00:00:00 > /usr/lib/evolution/2.12/evolution-exchange-storage > --oaf-activate-iid=OAFIID:GNOME_Evolution_Exchange_Component_Factory:2.12 > --oaf-ior-fd=27 > psmith1561 1 0 15:40 ?00:00:00 > /usr/lib/evolution/2.12/evolution-alarm-notify > --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.12 > --oaf-ior-fd=29 > > (Before I started /opt/evo/bin/evolution there were no processes running > containing the string "evo"). > > Can anyone tell me why it always invoking the stuff in /usr/lib, instead > of the stuff in /opt/evo/lib, even though I've set LD_LIBRARY_PATH, > BONOBO_ACTIVATION_PATH, etc. etc.? And, how to change this? I think the problem is that bonobo-activation-server is already running from /usr and only knows about the /usr components, and so when evolution requests them, it starts from from there rather than from /opt Hope that helps... Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] read email in an easier way by adding some accelerated keys
Personally I find your choice of ordering of J/K and S/D odd for next/prev, seems to me they should be flipped. Also, your gtk_paned_size == 55 is unlikely to work for everyone The other problem is that those key bindings are hardly self-explanatory/discoverable :( Jeff On Fri, 2007-10-26 at 17:29 +0800, David Liang wrote: > I added some accel-keys to reading email faster. > Does anyone want to try? > > bug is here: > http://bugzilla.gnome.org/show_bug.cgi?id=490448 > patch is here: > http://bugzilla.gnome.org/attachment.cgi?id=97895&action=view > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GMail IMAP support in Evolution
On Thu, 2007-10-25 at 23:47 -0600, Sankar P wrote: > On Thu, 2007-10-25 at 10:13 -0400, Jeffrey Stedfast wrote: > > I have a feeling, though, that the main reason Evo is so much slower > > than Outlook is due to the summary info gathering which (used to?) > > grab > > all the mailing-list headers as well as the normal stuff in order to > > be > > able to vfolder on mailing-list. > > > I have made this as a configurable option and if the user does not want > to fetch mailing-list headers he can choose to. (Though the default is > that it will fetch) Ok, I thought I remembered someone doing that but I wasn't sure :) > > However, I am doubtful though how many users will be aware of what a > mailing-list header is. > > nod. There are quite a few of them, even I couldn't name them all off the top of my head :( Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Let the porting begin
On Fri, 2007-10-26 at 03:25 +0200, Philip Van Hoof wrote: > On Wed, 2007-10-24 at 11:58 -0400, Jeffrey Stedfast wrote: > > I took a look at the IDLE implementation last night and felt it went > > about it the wrong way. > > Yes, you are right. I think the right fix is to create a new API called > camel_tcp_stream_wait that works like this: > > > int bytes = camel_tcp_stream_wait (tcp_stream, stop_fd, >store->idle_sleep, line_buffer, 1023); [snip] I was thinking more along the lines of making the idle_loop use PRPoll()/poll() itself - it already has to figure out what type of fd to create for the cancel_idle_fd anyway. > > Afaics It's not true that you don't need to change any API: > > The camel_stream_read() will block until all n bytes are read. no it doesn't. it returns as soon as any number of bytes are read or an error occurs. > This is > something you don't know during IDLE (how many bytes you can expect to > receive), and on top of that you want to continue immediately after > select returns, not keep retrying until you have n bytes (to simulate a > blocking read). sure, but that's why you poll yourself. once the socket has data, /then/ you call camel_stream_read() on it. > You also want a dedicated stop fildescriptor, not the > standard cancel_fd as then any cancel will interfere with this (while > you want strict control over this to let other threads start and stop > IDLE). right, but if you add a CamelStream API, then you have to add 1 for unix fds and 1 for PRFileDesc plus it keeps the code simpler (keeps all read() logic in the camel_stream_read() implementations rather than duplicating it). This actually brings me to another thought I've had for a few years now but haven't bothered pushing for it... but it might be best if all of the sockets used PRFileDesc rather than unix fd for raw sockets and PRFileDesc for SSL sockets. If this is done, I think it'd be possible to get rid of CamelTcpStreamRaw and move the implementation into CamelTcpStream and make CamelTcpStreamSSL a simple subclass of CamelTcpStream, replacing the CamelTcpStream's PRFileDesc with an SSL-wrapped fd as appropriate and calling parent_class->read/write/etc instead of implementing them all itself /again/. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GMail IMAP support in Evolution
One thing you could do which would be of use would be to sniff the packets that Outlook sends to Google Mail's IMAP and log them for the Evolution developers to read so that perhaps they can see what queries Outlook is doing that is so much faster than what Evolution is doing and maybe try to mimic Outlook. I have a feeling, though, that the main reason Evo is so much slower than Outlook is due to the summary info gathering which (used to?) grab all the mailing-list headers as well as the normal stuff in order to be able to vfolder on mailing-list. Jeff On Wed, 2007-10-24 at 13:11 +0200, Øystein Gisnås wrote: > Google seem to be in the process of introducing IMAP support to GMail > [1]. Personally I think GMail offers an extremely attractive email > solution by now. Evolution does already support integration with GMail > via SMTP and POP, and now also via IMAP. In addition to following the > IMAP standards as closely as possible, I think we should do explicit > QA on Evolution-GMail IMAP integration, to make sure our users' > experience is as good as possible. One of the slashdot comments has > already commented that Outlook works better with GMail IMAP than > Evolution. That should change! > > I've only used tested Evolution-GMail IMAP for a few minutes so far, > but already found a minor issue: I'm not able to prevent sent mail > from being stored. SMTP through GMail saves sent mails automatically. > > First of all, I'll recommend everyone to try out GMail IMAP, and then > I hope some initiative will be taken to QA this integration. > > Cheers, > Øystein > > [1] http://slashdot.org/article.pl?sid=07/10/24/0249257 > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Let the porting begin
I took a look at the IDLE implementation last night and felt it went about it the wrong way. Firstly, the added camel_stream_[read,write]_nb() and camel_stream_read_idle() functionality is totally unnecessary and just makes the camel stream API gross (not to mention duplicating a lot of code as there's no real difference from the normal read/write implementations other than the timeout). You should simply poll() on the socket descriptors (and a pipe fd used for telling the IDLE thread's I/O loop to finish and send DONE). Jeff On Mon, 2007-10-08 at 00:41 +0200, Philip Van Hoof wrote: > On Sun, 2007-10-07 at 14:15 +0200, Philip Van Hoof wrote: > > Hi there, > > > Using this changeset you can follow the changes to camel-lite: > > > > http://tinymail.org/trac/tinymail/changeset/2823 > > > > This changeset are a bunch of compilation warnings for Matthew's Base64 > patch to Camel: http://tinymail.org/trac/tinymail/changeset/2827 > > > ps. Adding Matthew in CC. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] There's no need to be so hard on iconv
On Thu, 2007-10-11 at 19:49 +0200, Philip Van Hoof wrote: > On Thu, 2007-10-11 at 13:10 -0400, Jeffrey Stedfast wrote: > > On Thu, 2007-10-11 at 17:14 +0200, Philip Van Hoof wrote: > > > On Thu, 2007-10-11 at 10:52 -0400, Jeffrey Stedfast wrote: > > > > I have far better fixes in GMime that need to be ported to Camel. > > > > > > > > > > Porting GMime to Camel would be an interesting effort indeed. Perhaps > > > just replacing CamelMimePart with GMime. > > > > Well... I hadn't exactly meant that it would be a good idea to > > necessarily replace Camel's MIME parser/objects with GMime. I had simply > > meant for Camel to lift GMime's rfc2047 decoder logic which does more > > with charset fallback than Camel currently does... plus it also is a bit > > more liberal in decoding malformed rfc2047 encoded-word tokens (well, > > assuming ENABLE_RFC2047_WORKAROUNDS is defined...). > > Aha, so we can just look at what we find in the #ifdef > ENABLE_RFC2047_WORKAROUNDS #endif blocks and learn for your effort :) well, you probably want all the code from those functions, even w/o the #ifdef (that #ifdef really only works around the problem where encoded-word tokens which are in the middle of other word tokens) in order to get the charset fixes as well. > > Cool, thanks. (note. isn't spruce GPL and Camel LGPL?) > Well, GMime is separate from Spruce... but yea, I just realised GMime is GPLv2+ - however, obviously I have an interest in improving Evolution and so I give permission to Evo to use that code ;) I need to poke the people who've contributed bits of code to GMime (the code I mentioned in this thread was all implemented by me, so it's safe to take) and make sure it's ok with them, but I'm likely going to relicense GMime to be LGPLv2+ Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] There's no need to be so hard on iconv
On Thu, 2007-10-11 at 17:14 +0200, Philip Van Hoof wrote: > On Thu, 2007-10-11 at 10:52 -0400, Jeffrey Stedfast wrote: > > I have far better fixes in GMime that need to be ported to Camel. > > > > Porting GMime to Camel would be an interesting effort indeed. Perhaps > just replacing CamelMimePart with GMime. Well... I hadn't exactly meant that it would be a good idea to necessarily replace Camel's MIME parser/objects with GMime. I had simply meant for Camel to lift GMime's rfc2047 decoder logic which does more with charset fallback than Camel currently does... plus it also is a bit more liberal in decoding malformed rfc2047 encoded-word tokens (well, assuming ENABLE_RFC2047_WORKAROUNDS is defined...). Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] There's no need to be so hard on iconv
I have far better fixes in GMime that need to be ported to Camel.
Jeff
On Thu, 2007-10-11 at 12:14 +0200, Philip Van Hoof wrote:
> I also have this one, for example
>
> Subject: =?ISO-2022-JP?B?GyRCJSIlaiUsLUUtRRsoQg==?= (
> =?ISO-2022-JP?B?GyRCITchJiZYISYbKEI=?=)o
> =?ISO-2022-JP?B?GyRCIlwbKEI=?=
> =?ISO-2022-JP?B?GyRCIiglUSE8JXMbKEI=?= !!"
> =?ISO-2022-JP?B?GyRCISMhJhsoQg==?= :*: =?ISO-2022-JP?B?GyRCISYbKEI=?=
> =?ISO-2022-JP?B?GyRCISwheRsoQg==?=
>
> I know that the characters " (", ")o ", " !!" and " :*: " should not be
> there (at least, I think they shouldn't), I guess this is done by spam
> bots to confuse spamassassin (not sure, though).
>
> This check in the code (line 842 in camel-mime-utils.c) makes any such
> string become the base64 one. This is of course really not readable for
> normal human beings (although, it depends on what you call a normal
> one).
>
> 842: .. /* quick check to see if this could possibly be a real encoded word */
> 843: .. if (len < 8 || !(in[0] == '=' && in[1] == '?' && in[len-1] == '=' &&
> in[len-2] == '?')) {
> 844: .. d(printf("invalid\n"));
> 845: .. return NULL;
> 846: .. }
>
> When just trying to decode the string, ignoring the check, it does work
> quite well. At least for this case.
>
> I'm attaching yet another patch that ignores this check.
>
>
> On Thu, 2007-10-11 at 11:52 +0200, Philip Van Hoof wrote:
> > In case iconv does not succeed in decoding for example the Subject
> > header, it returns the base64 encoded one. That is is obviously not
> > readable at all. The decoded one after base64 decoding (which did
> > succeed in my test case) or whatever iconv could recover from it, sounds
> > like a better option.
> >
> > This changeset (patch) on camel-mime-utils.c deals with the error
> > situation (in case iconv did not return -1) by returning what(ever)
> > iconv could recover from the string:
> >
> > http://tinymail.org/trac/tinymail/changeset/2830#file2
> >
> > I attached:
> >
> > svn diff libtinymail-camel/camel-lite/camel/camel-mime-utils.c -r 2829 >
> > /home/pvanhoof/diff.diff
> >
> > This is the Subject line of my test target:
> >
> > Subject: =?ISO-2022-JP?B?GyRCM048QiRLOkdEY0Z8NWsbKEI=?=
> >
> > =?ISO-2022-JP?B?GyRCIzJLfDFfIUFGfEonJCQkRyQqRU8kN0NXJDckXiQ5ISMlYSE8GyhC?=
> > =?ISO-2022-JP?B?GyRCJWslXiUsJTglcxsoQg==?=
> >
> >
> > I also opened a bug for this one:
> > http://bugzilla.gnome.org/show_bug.cgi?id=485677
> >
> >
> > ___
> > Evolution-hackers mailing list
> > Evolution-hackers@gnome.org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright of Camel's individual source files
On Tue, 2007-10-09 at 13:33 -0300, standel wrote: > > On Tue, 2007-10-09 at 17:22 +0200, Philip Van Hoof wrote: > > > On Tue, 2007-10-09 at 10:48 -0400, Jeffrey Stedfast wrote: > > > > It was supposed to be GPLv2 or LGPLv2 (forget which), but without the > > > > "or later" clause. > > > > > > For what it's worth, it would be more easy for projects like OpenChange > > > and Tinymail if the work would either be dual licensed as LGPL v2 and > > > LGPL v3 or with the "or later" clause. > > > > > > The problem would be that otherwise if the authors of these libraries > > > would want to move their work to a newer version of the LGPL license, > > > Camel's license might turn out to be incompatible with this. > > > > > > Which is something to avoid, I think. > > > > It doesn't work that way... (L)GPLv3 apps/libs can use (L)GPLv2 libs > > without a problem, it's the other way around that doesn't work. > > > > I fear it's not that simple! see the GPL compatibility matrix : > http://fedoraproject.org/wiki/Licensing#head-699ce10b1f5d466cd4c3d61301c3651f0c2ca219 > > you can't release a project under (L)GPLv3 if you're using a lib under > GPLv2-only. Apps under GPLv3 can link fine to EDS if EDS is licensed LGPLv2-only just fine according to that matrix. Jeff > > > Regards, > Sebastien Tandel > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright of Camel's individual source files
On Tue, 2007-10-09 at 13:33 -0300, standel wrote: > > On Tue, 2007-10-09 at 17:22 +0200, Philip Van Hoof wrote: > > > On Tue, 2007-10-09 at 10:48 -0400, Jeffrey Stedfast wrote: > > > > It was supposed to be GPLv2 or LGPLv2 (forget which), but without the > > > > "or later" clause. > > > > > > For what it's worth, it would be more easy for projects like OpenChange > > > and Tinymail if the work would either be dual licensed as LGPL v2 and > > > LGPL v3 or with the "or later" clause. > > > > > > The problem would be that otherwise if the authors of these libraries > > > would want to move their work to a newer version of the LGPL license, > > > Camel's license might turn out to be incompatible with this. > > > > > > Which is something to avoid, I think. > > > > It doesn't work that way... (L)GPLv3 apps/libs can use (L)GPLv2 libs > > without a problem, it's the other way around that doesn't work. > > > > I fear it's not that simple! see the GPL compatibility matrix : > http://fedoraproject.org/wiki/Licensing#head-699ce10b1f5d466cd4c3d61301c3651f0c2ca219 > > you can't release a project under (L)GPLv3 if you're using a lib under > GPLv2-only. > Sounds like the FSF have screwed the pooch on this new license then, don't it? ;) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright of Camel's individual source files
(been having problems with the novell smtp server sending mail, so apologies if this goes out twice). On Tue, 2007-10-09 at 17:22 +0200, Philip Van Hoof wrote: > On Tue, 2007-10-09 at 10:48 -0400, Jeffrey Stedfast wrote: > > It was supposed to be GPLv2 or LGPLv2 (forget which), but without the > > "or later" clause. > > For what it's worth, it would be more easy for projects like OpenChange > and Tinymail if the work would either be dual licensed as LGPL v2 and > LGPL v3 or with the "or later" clause. > > The problem would be that otherwise if the authors of these libraries > would want to move their work to a newer version of the LGPL license, > Camel's license might turn out to be incompatible with this. > > Which is something to avoid, I think. This is exactly why we want it to be LGPLv2 (pretty confidant that Camel - if not all of EDS - is supposed to be LGPLv2 and not GPLv2 - it's one of the reasons Werner Koch was considering relicensing GPGME to be LGPL instead of GPL at one point, forget if he actually made the change or not) and not (L)GPLv3 because software licensed under v3 of the license can use v2 libs w/o any issues, but v2 cannot use v3. There shouldn't be a need to dual license LGPLv2 & LGPLv3, it should be plenty to simply keep the LGPLv2 license that Camel is already under. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright of Camel's individual source files
On Tue, 2007-10-09 at 17:22 +0200, Philip Van Hoof wrote: > On Tue, 2007-10-09 at 10:48 -0400, Jeffrey Stedfast wrote: > > It was supposed to be GPLv2 or LGPLv2 (forget which), but without the > > "or later" clause. > > For what it's worth, it would be more easy for projects like OpenChange > and Tinymail if the work would either be dual licensed as LGPL v2 and > LGPL v3 or with the "or later" clause. > > The problem would be that otherwise if the authors of these libraries > would want to move their work to a newer version of the LGPL license, > Camel's license might turn out to be incompatible with this. > > Which is something to avoid, I think. It doesn't work that way... (L)GPLv3 apps/libs can use (L)GPLv2 libs without a problem, it's the other way around that doesn't work. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright of Camel's individual source files
The license should read GPLv2 (no "or later" clause) as far as I know. Jeff On Mon, 2007-10-08 at 12:08 +0200, Philip Van Hoof wrote: > Hi there, > > The README.COPYRIGHT of EDS's Camel states: > > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License as > * published by the Free Software Foundation; either version 2 of the > * License, or (at your option) any later version. > > Whereas a lot of files (like, camel-address.c, to pick one example) state: > > * This program is free software; you can redistribute it and/or > * modify it under the terms of version 2 of the GNU Lesser General Public > * License as published by the Free Software Foundation. > > It looks like EDS's COPYING file also uses the "any later version" > version of the GPL v2. > > I'm not sure whether it's a good idea to have mixed licenses for one > piece of code (being Camel). Would it be possible to change the license > of all of EDS's files to be the same? > > Note that Novell/Ximian seems to be the copyright holder of all files, > that of course means this organisation makes this decision. > > > Thanks! > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright of Camel's individual source files
It was supposed to be GPLv2 or LGPLv2 (forget which), but without the "or later" clause. Jeff On Tue, 2007-10-09 at 16:19 +0530, Srinivasa Ragavan wrote: > Philip, > > This is observed in Evolution also. The OpenChange hackers brought to > our notice and I'm with the Novell legal team to get this resolved > altogether. But that process seems like taking time and I have to wait a > but before doing anything. > > -Srini. > > On Mon, 2007-10-08 at 12:08 +0200, Philip Van Hoof wrote: > > Hi there, > > > > The README.COPYRIGHT of EDS's Camel states: > > > > * This program is free software; you can redistribute it and/or > > * modify it under the terms of the GNU General Public License as > > * published by the Free Software Foundation; either version 2 of the > > * License, or (at your option) any later version. > > > > Whereas a lot of files (like, camel-address.c, to pick one example) state: > > > > * This program is free software; you can redistribute it and/or > > * modify it under the terms of version 2 of the GNU Lesser General Public > > * License as published by the Free Software Foundation. > > > > It looks like EDS's COPYING file also uses the "any later version" > > version of the GPL v2. > > > > I'm not sure whether it's a good idea to have mixed licenses for one > > piece of code (being Camel). Would it be possible to change the license > > of all of EDS's files to be the same? > > > > Note that Novell/Ximian seems to be the copyright holder of all files, > > that of course means this organisation makes this decision. > > > > > > Thanks! > > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Let's clean up dead files in Subversion trunk
I probably wouldn't get rid of mail/README.async, that's useful knowledge in there iirc. Jeff On Thu, 2007-09-20 at 15:14 -0400, Matthew Barnes wrote: > With GNOME 2.22 development just now getting under way, this seems like > a good time for some fall cleaning. There's quite a few files still > living in Subversion trunk that we did not ship for GNOME 2.20. > > I've filed a series of bug reports about this, hoping that we can > collectively sift through the lists and decide what should stay and what > should go, as maybe spot files we *should* have shipped that got > overlooked. > > I'm of the opinion that, in general, trunk should only contain what we > ship. If we need to resurrect a file down the road we can always fetch > it from SCM archives. Keeping dead, unshipped source code files in > trunk is especially detrimental to developers because someone will > inevitably waste time maintaining them, not realizing or forgetting > they're dead. I've lost track of the number of times this has happened > to me. > > Here's the list of bug reports. Please to comments about specific files > to the appropriate bug. > > http://bugzilla.gnome.org/show_bug.cgi?id=478704 (Evolution) > http://bugzilla.gnome.org/show_bug.cgi?id=478692 (Evolution-Data-Server) > http://bugzilla.gnome.org/show_bug.cgi?id=478680 (Evolution-Exchange) > http://bugzilla.gnome.org/show_bug.cgi?id=478670 (GtkHtml) > > Matthew Barnes > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS: Trying to implement expunge function in camel-spool-folder.c
On Mon, 2007-06-25 at 23:05 +0100, Seb James wrote: > On Mon, 2007-06-25 at 14:25 +0100, Seb James wrote: > > Hi Jeffrey, > > > > On Mon, 2007-06-25 at 08:59 -0400, Jeffrey Stedfast wrote: > > > On Sun, 2007-06-24 at 23:24 +0100, Seb James wrote: > > [snip] > > > from your description, it sounds like you tried to Empty the "Local > > > Folders" Trash folder instead of the Trash folder attached to your > > > "spool". > > > > Yes, that's what I think has happened. > > > > > You should also note that since the Trash folder is a virtual folder, > > > unless both of the following conditions are met, you might not get an > > > expunge call on the spool folder: > > > > Useful to know that trash is virtual. That will help me I think. I can > > look at the logic that the vTrash folder goes through to select expunges > > and syncs to call. > > Ok, now that I am debugging the right code... Yes, the expunge function > registered for the Trash folder is vee_expunge in camel-vee-folder.c. > vee_expunge has one line: > > ((CamelFolderClass *)((CamelObject *)folder)->klass)->sync(folder, TRUE, > ex); > > So, it calls the sync function. Correct me if I'm wrong, but it looks > like any folder which is to implement message expunging when the user > clicks "Empty Trash" needs to implement the _sync_ function in such as > way that deleted messages really can be expunged. Writing an mbox or > spool expunge function won't work as it won't get called via a vTrash > folder expunge. sounds correct, yes. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] filtertypes.xml and Camel command reference
On Mon, 2007-06-25 at 11:28 +1200, chris burgess wrote:
> We're keen to modify the available filter actions for our custom
> packaged (ubuntu, evo 2.10.1) installs of Evolution.
>
> In filtertypes.xml, it looks like I can add a new entry
> if I know what the required commands to call are. I see entries like,
>
>
> Copy to Folder
> (copy-to ${folder})
>
>
>
> The block is a sexpression calling a Camel binding or function
> (not sure of the terminology here).
>
> 1. Is there a canonical list (autodocs?) of what calls are available
> to use here?
the only lists I know of are in the source code... I don't know of any
docs that explain them, unfortunately.
the list of match rules are in camel-folder-search.c in the 'builtins'
table.
the list of filter actions are listed in camel-filter-driver.c in a
table called 'symbols'
as far as what the arguments are, I don't recall off the top of my head
for each one, so you'll have to read the callback functions for each of
those to figure it out.
>
> 2. Is it possible to affect the available actions in the filter
> creation dialog simply by adding new entries here, or are other code
> changes required?
changing the xml file will make them appear in the list and will work.
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS: Trying to implement expunge function in camel-spool-folder.c
On Sun, 2007-06-24 at 23:24 +0100, Seb James wrote: [snip] > > All I'm trying to do to start with is get a message to print out on > stdout. In the function camel_spool_folder_class_init() I create a > CamelFolderClass pointer to the CamelSpoolFolderClass passed in, so that > I can then replace the expunge function pointer in that > class/structure. > > When I run evolution, and try to expunge the spool based inbox by > right-clicking on the Trash folder and selecting "Empty > Wastebasket" (that might read "Empty Trash" for a US locale), then a > debugging message that I placed in camel-folder.c tells me this: > > camel-folder.c(562): camel_folder_expunge called for folder->name > 'Trash', with parent_store->parent_service name 'Local mail > file /home/seb/.evolution/mail/local/', path > 'mbox/home/seb/.evolution/mail/local' > > What this is saying is that eds is not trying to call the > CamelSpoolFolderClass version of expunge, instead it is calling the > expunge which relates to the local mail file mentioned. This means that > eds then goes on to call camel_folder_sync for all the local folders, > instead of calling the CamelSpoolFolderClass implementation of expunge. > > Can anyone tell me how to get the CamelLocalFolder/CamelSpoolFolder > expunge to be called? How come the trash icon that gets placed next to > my spool INBOX doesn't cause a spool based expunge to be called? > from your description, it sounds like you tried to Empty the "Local Folders" Trash folder instead of the Trash folder attached to your "spool". You should also note that since the Trash folder is a virtual folder, unless both of the following conditions are met, you might not get an expunge call on the spool folder: 1. you have opened the spool folder (at one point, not sure if it is still true, vTrash folders, for performance reasons, would not 'notice' physical folders until they had been opened) 2. the spool folder has messages marked for deletion (vTrash might have logic to skip folders that contain no deleted messages when calling expunge on all their source folders) It might be better to invoke "Expunge Folder" on the physical spool folder itself while debugging this as there is a lot less indirection. > > > I'm also having trouble debugging eds using gdb and the edsdebug script > that I got from the evolution website. If I try to break on > camel_folder_sync, gdb tells me it doesn't know where it is... > > (gdb) b camel_folder_expunge > Function "camel_folder_expunge" not defined. > Make breakpoint pending on future shared library load? (y or [n]) > > But some camel functions are available: > > (gdb) b camel_f[TAB] > camel_file_util_decode_fixed_int32 camel_file_util_decode_uint32 [snip > rest of camel_file_ functions] > > Can anyone tell me what I'm doing wrong here? > you don't want to be gdbing e-d-s, e-d-s barely uses camel at all - just uses a few functions (perhaps that's why those are defined and the others not). e-d-s is a daemon process that serves up calendar and addressbook data, it doesn't serve up mail. You want to gdb evolution itself. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Mon, 2007-06-11 at 12:04 -0700, Ross Boylan wrote:
> > > > it is indeed a synchronous API :)
> > > Syncronous, but it fails the "you know if you've succeeded when the
> > > function returns" test.
> >
> > most of the camel APIs don't fail that test
> >
> This was in the context of something I was thinking of ("So it sounds as
> if Camel could "). The feature/change I was contemplating sounds as
> if it would be a bad idea because it violates the usual model for camel
> calls.
ah, gotcha. yes, I'd agree :)
> Probably either a smaller change (keeping the
> blocking/syncronous/useful return values in place) or a bigger one
> (general asyncronicity) would be a better idea--at least in a perfect
> world of infinite coding time.:) In fact, your idea with folder open
> preserves the expected features of the camel API.
yep :)
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Data Cache mechanism
On Mon, 2007-06-11 at 15:27 -0300, Sebastien Tandel wrote: > Hi, > > >I am looking at the way CAMEL is working and have some questions > about the cache implementation. > > First, let's see if I've understood the mechanism basics (and, of > course, don't hesitate to correct me if I'm wrong :)) > > Camel has a "generic" cache system which stores objects in Camel Bags. > This camel data cache uses CamelStreamFs to store the "real" objects we > want to cache. According to the way it is implemented now : > - It is not possible to bound the size of a cache. There only exists > timer for expiration/invalidation data. > - And each of these CamelStreamFs uses a path build by the IMAP provider > (in my case). This path is built with session->storage_path and > camel_service_get_path() but I was unable to determine the value of > session->storage_path. I made here the hypothesis all the objects are > stored on the disk ... > > Based on these assumptions, here are the questions : > 1) To what I've seen, the cache is on a fs ... Is there any project > which intends to have some cache in the main memory? or is there a > possibility to use a tmpfs? not afaik. > 2) Could we imagine to be able to limit the size of the cache? I don't see any reason why this couldn't be implemented :) > > I was wondering whether it could be possible to have a mechanism which > would be like a two-level cache. The first level is the main memory of a > size X, in which are stored the more recent accessed objects and the > second level the hard disk with as well a bounded size if possible and > finally access the network if the information is not cached. > Is that a crazy idea? Or are there already some mechanisms implemented > I've not seen? Is there any reason to do this? What problem would you be solving? The cache is typically only used for messages from a remote host (in fact, I can't think of anything else it's used for). The problem with trying to keep an in-memory cache is that users don't typically keep hitting the same message, so there seems to be little point in having an in-memory cache on top of the disk cache. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Mon, 2007-06-11 at 09:46 -0700, Ross Boylan wrote: > I'm preserving the exchange for context; my responses are sprinkled > below. > On Sun, 2007-06-10 at 23:47 -0400, Jeffrey Stedfast wrote: > > On Sun, 2007-06-10 at 15:55 -0700, Ross Boylan wrote: > > > On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote: > > > > > > > > > > Second question: even if it creates a folder, does it need to stick > > > > > around for the folder creation to finish? I think I remember seeing > > > > > that camel was single-threaded > > > > > > > > not true... > > > > I should have been clearer here: > > > > yes, it needs to wait for the folder object instantiation to finish (the > > function returns a pointer to the instantiated object, afterall). > And your proposal with "open" on that object is designed to decouple > creation of the object from creation of the summary, right? correct, the ::open() would load the summary from disk and (if the store is network based), sync state with the server (find out about messages which were deleted since last session, flag changes, new messages, etc) > When I said > "folder creation" I was thinking of the whole get headers and make index > process. ok > > > > not true that camel is single-threaded - it has a few of its own threads > > going - most notably is the thread for filtering incoming mail for > > providers like imap and maildir (they share the same thread). > > > > > > > > > > > , relying on the client app to do > > > > > threading. Would there be a way to multi-thread this somewhere > > > > (either > > > > > in camel or in the app)? Obviously doing so would complicate > > > > things, > > > > > because at some point one might need to block (e.g., if I move a > > > > message > > > > > from folder A to B and then switch the UI to look at B). > > > > > > > > okay, I think you need to familiarize yourself with Camel's API before > > > > we discuss anything further :) > > > > > > > http://www.go-evolution.org/Mail_Threading begins > > > "The Camel API is blocking and synchronous" > > > although it then goes on to qualify this: > > > "Custom Threads > > > Two tasks inside Camel use threads internally in order to implement a > > > cancellable api ontop of a non-cancellable one." > > > > > > Further > > > "Mail-OPS > > > mail-ops.h contains asynchronous versions of varous Camel api's" > > > It sounds as if mail-ops is outside of Camel, however. > > > > it is external to camel, yes. > > > > > > > > So it sounds as if Camel could (in principle) respond to a move request > > > by issuing the appropriate IMAP command and then, starting a thread to > > > do the other activities (indexing the target folder and deleting the the > > > message from the source folder) and return. > > > > it could, yes, but it'd need a way to report an error unless it waited > > for the operations to finish before returning. For moving mail, you > > typically want to know that it succeeded :) > > > > all of the current camel APIs are designed such that the caller expects > > that when the function returns, the operation has either succeeded or > > failed (where the failure would be set on the CamelException argument). > > > > > It would then block on > > > operations that attempted to access the target folder until the other > > > operations completed. > > > > yes, this is true... well, the way folders are implemented at this time > > anyway... > > > > > > > > I think this could be called a syncronous API, though perhaps that's a > > > stretch. > > > > it is indeed a synchronous API :) > Syncronous, but it fails the "you know if you've succeeded when the > function returns" test. most of the camel APIs don't fail that test > > > > > > > > On the other hand, http://www.go-evolution.org/Camel.Operation does not > > > sound like a bocking syncronous API at all, so maybe the statement > > > quoted at the top is just obsolete? > > > > Camel code is written under the assumption that it is likely it is being > > used in a thread, so it has CamelOperation as a means to: > > > > 1. report the progress > > 2. cancel operations (typically i/o) > &
Re: [Evolution-hackers] Introduction and Questions
On Sun, 2007-06-10 at 15:55 -0700, Ross Boylan wrote: > On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote: > > > > > > Second question: even if it creates a folder, does it need to stick > > > around for the folder creation to finish? I think I remember seeing > > > that camel was single-threaded > > > > not true... I should have been clearer here: yes, it needs to wait for the folder object instantiation to finish (the function returns a pointer to the instantiated object, afterall). not true that camel is single-threaded - it has a few of its own threads going - most notably is the thread for filtering incoming mail for providers like imap and maildir (they share the same thread). > > > > > , relying on the client app to do > > > threading. Would there be a way to multi-thread this somewhere > > (either > > > in camel or in the app)? Obviously doing so would complicate > > things, > > > because at some point one might need to block (e.g., if I move a > > message > > > from folder A to B and then switch the UI to look at B). > > > > okay, I think you need to familiarize yourself with Camel's API before > > we discuss anything further :) > > > http://www.go-evolution.org/Mail_Threading begins > "The Camel API is blocking and synchronous" > although it then goes on to qualify this: > "Custom Threads > Two tasks inside Camel use threads internally in order to implement a > cancellable api ontop of a non-cancellable one." > > Further > "Mail-OPS > mail-ops.h contains asynchronous versions of varous Camel api's" > It sounds as if mail-ops is outside of Camel, however. it is external to camel, yes. > > So it sounds as if Camel could (in principle) respond to a move request > by issuing the appropriate IMAP command and then, starting a thread to > do the other activities (indexing the target folder and deleting the the > message from the source folder) and return. it could, yes, but it'd need a way to report an error unless it waited for the operations to finish before returning. For moving mail, you typically want to know that it succeeded :) all of the current camel APIs are designed such that the caller expects that when the function returns, the operation has either succeeded or failed (where the failure would be set on the CamelException argument). > It would then block on > operations that attempted to access the target folder until the other > operations completed. yes, this is true... well, the way folders are implemented at this time anyway... > > I think this could be called a syncronous API, though perhaps that's a > stretch. it is indeed a synchronous API :) > > On the other hand, http://www.go-evolution.org/Camel.Operation does not > sound like a bocking syncronous API at all, so maybe the statement > quoted at the top is just obsolete? Camel code is written under the assumption that it is likely it is being used in a thread, so it has CamelOperation as a means to: 1. report the progress 2. cancel operations (typically i/o) what happens is Evolution has a thread-pool with a CamelOperation object for each of the threads the mailer creates so that it can cancel operations and/or get progress updates. > > So, first of all I'm confused about the nature of Camel's API and > operation as far as threading and syncronicity. > > Second, I don't have a sense of whether its features are historical > accidents (camel was implemented in a simple way and evo then used it as > it was) evolution mailer was originally not multi-threaded if my recollection serves correctly, although around the time of the first 0.0 release threading was added (about 7 years ago). camel and evolution were developed together, so their "designs" evolved together. > or the result of some deliberate design decisions. Blocking > syncronous operations are simpler to implement, yep > to use, yep > to debug, yep, altho with threads thrown in and gdb multi-thread support sucking, this was still a nightmare... > and to > understand, so they clearly have some advantages. But it seems that > the entire application (evolution) does not have that character, so the > benefits of that simplicity end up lost anyway. I'm not sure I understand what you mean here... I guess what you are saying is that evolution code isn't easy to understand. I think that's true for all large/complex projects. I think that it also feels that way when you are new to the project because it is so large and overwhelming - I mean, I know that's how I'd feel if I were just getting into Evolution sources... I think that it probably doesn't help
Re: [Evolution-hackers] Introduction and Questions
On Sun, 2007-06-10 at 11:39 +0300, Philip Van Hoof wrote: > On Sat, 2007-06-09 at 08:14 -0400, Jeffrey Stedfast wrote: > > > server says: > > > > * 1 EXPUNGE > > > > camel-imap-summary does: > > > > g_ptr_array_remove_index (messages, seqid - 1); > > In imap_rescan, for example in case a message got removed by another > E-mail client while this E-mail client was not online. > A hash table won't solve this... Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Sat, 2007-06-09 at 13:00 +0300, Philip Van Hoof wrote: > What I disliked most about Camel's 'imap' code, though, is the fact that > the sequences have to correspond to the array indexes of the > CamelFolderSummary. It sounds like it would have been more easy if that > was a key in a hashtable. ...??? are you serious? > > For example if a message got expunged that had a sequence value in the > beginning of the folder, it right now more or less means that the entire > folder has to be re-synchronised. While the majority of the local data > can be perfectly corrected in stead too. huh? it doesn't re-fetch anything, it simply removes the item from the array at the index given in the untagged EXPUNGE notification. server says: * 1 EXPUNGE camel-imap-summary does: g_ptr_array_remove_index (messages, seqid - 1); (seqid in this case would be '1', but keep in mind that IMAP seqids start at 1 while in c, array indexes start at 0) How would a hash table simplify this? It'd only serve to complicate things because you'd have to re-key the entire hash table after each EXPUNGE notification. Not to mention it would consume a fair bit more memory... Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 17:43 -0700, Ross Boylan wrote: > On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote: > > > Why does it need to create a CamelFolder for the destination at all, > > > assuming I keep the focus on the source folder? > > > > because you need both a source and a destination folder to move the > > message(s) to? > > > > kinda hard to move messages to a folder if you don't know which folder > > to move them to, don't you agree? :) > All you need for IMAP is the name of the target folder, not the fuller > representation that CamelFolder provides. In particular, there's no > need to fetch the headers from the destination folder, index them, etc. It allows the destination folder to do bookkeeping that may improve performance (e.g. caching the message, adding summary info to the cache) as well as properly handling offline state (journal the move/append/whatever for disconnected operation so when the user went online and opened said folder, it could re-play the journal, etc) This is why I had proposed ::open() and ::close() methods on CamelFolders... instantiate a CamelFolder object just mallocs the memory and initializes member variables/whatever, it wouldn't open the summary or try to sync the summary over the network until ::open() was invoked. Later, calling ::close() would unload the summary/do whatever bookkeeping might be necessary. It's important to see the Big Picture(tm) when making design decisions :) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 18:34 +0300, Philip Van Hoof wrote: > The imap4 project is making things look better, though all in all it's > still much of the same (blocking and waiting for results, in stead of > letting the server do most the work and do pipelining). adding pipelining support would not be difficult to do, actually. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 16:02 -0700, Ross Boylan wrote: > On Fri, 2007-06-08 at 18:27 -0400, Jeffrey Stedfast wrote: > > On Fri, 2007-06-08 at 15:13 -0700, Ross Boylan wrote: > > > On Fri, 2007-06-08 at 17:11 -0400, Jeffrey Stedfast wrote: > > > > On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote: > . > > > All good points. I should explain I'm thinking of a mode that might > > > kick in only on "large" mailboxes, or as a user option or something like > > > that. My main concern is that with very large folders most mail cients, > > > including evolution, become sluggish to the point of being unusable. > > > For many of the clients life is much uglier during the initial contact > > > with the folders than later. For example, when I move a message into a > > > folder I haven't opened or operated on in evolution, I'm noticing long > > > delays (like > 1 minute) while it does something (fetch headers and > > > create an index? whatever it is uses some, but not all the CPU). > > > > yea, it's creating a summary. > > > > IMHO, the design needs to change such that a CamelFolder object need not > > load the summary when instantiated. If that gets implemented, then > > there's no need to hit the server to sync summary info before the object > > gets returned to the caller who requested it, thus allowing appends w/o > > this particular slowness. > > > > This is all part of my camel architecture redesign ideas that I had > > started implementing in libspruce as a testbed. I think Michael Zucchi > > even started to implement this in the disk-summary branch (it basically > > boiled down to ::open() and ::close() methods on a CamelFolder object) > > > Why does it need to create a CamelFolder for the destination at all, > assuming I keep the focus on the source folder? because you need both a source and a destination folder to move the message(s) to? kinda hard to move messages to a folder if you don't know which folder to move them to, don't you agree? :) > > Actually, I guess I don't know if IMAP copy/delete is happening behind > the scenes, or if camel is creating the message from scratch in the > target folder. The latter is a lot more work (though probably easier to > implement). it uses imap COPY and mark-as-deleted > > Second question: even if it creates a folder, does it need to stick > around for the folder creation to finish? I think I remember seeing > that camel was single-threaded not true... > , relying on the client app to do > threading. Would there be a way to multi-thread this somewhere (either > in camel or in the app)? Obviously doing so would complicate things, > because at some point one might need to block (e.g., if I move a message > from folder A to B and then switch the UI to look at B). okay, I think you need to familiarize yourself with Camel's API before we discuss anything further :) > > > > > > > In this context an responsive but imperfect solution is better than an > > > unresponsive perfect one. > > > > I would argue that it's not a perfect solution if it's unresponsive :) > For sure. > > > > > > > > For example, if evo relies on the server's threads then it will > > > obviously inherit their behavior, warts and all. In general I agree > > > with the point, made recently on this list, that it's desirable for > > > clients to shield users from server problems (and most users don't know > > > and don't care that the the "real" problem is with the server). But if > > > doing so takes forever, some may be willing to give up on that. > > > > > > Whether relaying on server side threading, which currently only operates > > > on the whole mailbox, can solve the performance problems is another > > > issue. > > > > it doesn't operate on the whole mailbox, it operates on a seqid or uid > > set afaik. > > > > been a while since I've read the specs > > > I was mistaken about threading being only for the whole box. I just > looked at > http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-18.txt and > see you can add additional search specifications to limit your thread > request. Of course, clients might still ask for all the threads. when you think about it, it's really the only way to do it. The only way to figure out which UIDs to display in the message-list 'window' in threaded mode depends on being able to calculate which rows to show. To do this, you need the whole thread model since y
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 15:13 -0700, Ross Boylan wrote: > On Fri, 2007-06-08 at 17:11 -0400, Jeffrey Stedfast wrote: > > On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote: > > > On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote: > > > > it's not possible to do better w/o dropping features like message > > > > threading. > > > > > > > > In fact, the above minimalizing of header fetching already breaks the > > > > quick context-menu "vfolder on mailing-list" and "filter on > > > > mailing-list" features as well as making vfoldering on mailing-list > > > > oodles slower (if it even still works after disabling the headers) > > > What about letting the server do the threading, if it can? > > > > 1. not all servers support it, so we need to implement threading > > client-side anyway > > > > 2. not all servers do it /correctly/, so we'd need to have a lookup > > table of server idents so we knew when to fallback (note that every mail > > client I know of that tried to be smart and let the server do the > > threading has lived to regret making this decision) > The parenthetical remark is pretty interesting. (Balsa is one such client, if you are interested) > > > > 3. if threading behavior is different from other accounts, it will feel > > "weird" to the user. > All good points. I should explain I'm thinking of a mode that might > kick in only on "large" mailboxes, or as a user option or something like > that. My main concern is that with very large folders most mail cients, > including evolution, become sluggish to the point of being unusable. > For many of the clients life is much uglier during the initial contact > with the folders than later. For example, when I move a message into a > folder I haven't opened or operated on in evolution, I'm noticing long > delays (like > 1 minute) while it does something (fetch headers and > create an index? whatever it is uses some, but not all the CPU). yea, it's creating a summary. IMHO, the design needs to change such that a CamelFolder object need not load the summary when instantiated. If that gets implemented, then there's no need to hit the server to sync summary info before the object gets returned to the caller who requested it, thus allowing appends w/o this particular slowness. This is all part of my camel architecture redesign ideas that I had started implementing in libspruce as a testbed. I think Michael Zucchi even started to implement this in the disk-summary branch (it basically boiled down to ::open() and ::close() methods on a CamelFolder object) > > In this context an responsive but imperfect solution is better than an > unresponsive perfect one. I would argue that it's not a perfect solution if it's unresponsive :) > > For example, if evo relies on the server's threads then it will > obviously inherit their behavior, warts and all. In general I agree > with the point, made recently on this list, that it's desirable for > clients to shield users from server problems (and most users don't know > and don't care that the the "real" problem is with the server). But if > doing so takes forever, some may be willing to give up on that. > > Whether relaying on server side threading, which currently only operates > on the whole mailbox, can solve the performance problems is another > issue. it doesn't operate on the whole mailbox, it operates on a seqid or uid set afaik. been a while since I've read the specs ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote: > On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote: > > it's not possible to do better w/o dropping features like message > > threading. > > > > In fact, the above minimalizing of header fetching already breaks the > > quick context-menu "vfolder on mailing-list" and "filter on > > mailing-list" features as well as making vfoldering on mailing-list > > oodles slower (if it even still works after disabling the headers) > What about letting the server do the threading, if it can? 1. not all servers support it, so we need to implement threading client-side anyway 2. not all servers do it /correctly/, so we'd need to have a lookup table of server idents so we knew when to fallback (note that every mail client I know of that tried to be smart and let the server do the threading has lived to regret making this decision) 3. if threading behavior is different from other accounts, it will feel "weird" to the user. > I realize > not all can, and probably all will seem not as smart as they could be > (or just different from how threading would be done in evolution). But > otherwise, there's no way around getting lots of headers, and that is a > huge hit with big folders. > > That's the theory; the practice seems uglier. I tried mulberry, which > is supposed to make very good use of IMAP. In many ways it does, but > its use of server-side threading doesn't work too well. It seemed to > get the response back quickly from the server, but then take minutes > processing and parsing this response. Furthermore, every time one > scrolls the window, it does it all over again. > > The other problem with server-side threading is that it threads > everything. In principle it might make more sense to retrieve a window > of headers and thread them. actually, I think this is what Mulberry is doing - or at least that would make sense if it has to re-fetch thread info when you scroll. > > The window might not include all items in the thread, but that seems a > reasonable trade-off to me in return for decent performance. One could > do a more thorough job in the background and update when it finished. but then you have items in the list moving around as more thread info becomes available which would be annoying to users, imho. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Fri, 2007-06-08 at 14:39 +0300, Philip Van Hoof wrote:
> On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote:
>
> > On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
>
> > > The best way is to ask for the ENVELOPE and the remaining info using the
> > > normal BODY.PEEK method.
> >
> > Have you actually ever tested this theory? or did you just pull this out
> > of your proverbial?
>
> I have. The ENVELOPE-way is slightly better because words like "From:"
> and "To:" are not repeated each time. Although with COMPRESS and/or
> support for deflate in the TLS/SSL library will probably compress that
> difference away mostly.
ENVELOPE alone is no doubt as fast or faster (hopefully faster) than
explicit header fetching (I expect most servers probably cache ENVELOPE
info, whereas explicit header fetching would have to be done by
re-parsing the message) and (probably) less processor intensive
server-side.
>
> Note I didn't test this with compression. I saw a difference of 5% to
> 10% depending on several factors in bandwidth saving. I usually test all
> this with wireshark, which doesn't help a lot with compressed data. It
> would be nice, indeed, to get some analysis of how data is being
> compressed when compression by either COMPRESS or the SSL library is
> being done.
>
> Note that I haven't yet implemented COMPRESS in camel-lite, but I will
> do this very soon (I have a CamelStreamGzip thingy ready for this).
>
> On top of bandwidth, on pure speed a lot IMAP servers will return your
> result faster if you only use ENVELOPE. That's because they optimise on
> the fields that are in ENVELOPE (indexes, etc etc).
nod, which is why imap4 used ENVELOPE. I later had to add explicit
fetching of other headers, though, to maintain feature compat with imap.
>
> But then again, there's not enough in ENVELOPE to support all of
> Evolution's features, so you'll still have to use BODY.PEEK which will
> most likely slowdown everything back again.
indeed, and it doesn't appear to be faster trying to
use ENVELOPE + explicit header fetching, /probably/ because the server
still has to spend time parsing the actual message off disk, so the
performance gain of using ENVELOPE for the (typically? cached) summary
info is negated - possibly made even slower (server has to hit 2
code-paths instead of just the 1), but bandwidth is still slightly
decreased, possibly making up for the increased processing time.
>
> > You should note that Thunderbird does not use ENVELOPE, probably because
> > they found it was LESS efficient to fetch the ENVELOPE +
> > BODY.PEEK[HEADER.FIELDS (REFERENCES CONTENT-TYPE)] on many existing IMAP
> > servers in the wild.
>
> Probably, indeed.
>
> > Having myself tested this in the past, I don't recall it making much
> > difference one way or the other.
>
> On bandwidth, it does. Especially when you have a lot of messages in
> some folders and the server is not compressing things (no COMPRESS nor
> TLS/SSL compressing things for you).
ok, fair enough... not sure how much you really cut out tho, address
lists are likely more bandwidth intensive in the ENVELOPE response than
in raw format.
To: Jeffrey Stedfast <[EMAIL PROTECTED]>, Miguel de Icaza <[EMAIL
PROTECTED]>\r\n
ENVELOPE equiv:
(("Jeffrey Stedfast" NIL "fejj" "novell.com") ("Miguel de Icaza" NIL "miguel"
"ximian.com"))
You can see that the ENVELOPE response is more verbose, so the savings
really depends on individual messages.
You do save on the command echoing from the server, tho...
all in all, yea, probably you save some bandwidth. For most users,
ENVELOPE is probably a win as far as bytes-sent-across-the-wire.
The biggest win for ENVELOPE, in my opinion, is not bandwidth but server
processing (measured in both time and resources). Unfortunately, if you
have to explicitly request headers anyway, this is completely negated :(
>
> > Sadly using ENVELOPE breaks on at least one proprietary IMAP server
> > which occasionally likes to send back responses with NIL as each and
> > every item, at least until a client has issued a BODY.PEEK fetch
> > request.
>
> Sounds like a bug in that server implementation.
yes, it is.
>
> > > It should be possible to specify per folder
> > > which of the headers are to be fetched, to make it really efficient.
> >
> > how do you propose calculating the list of headers each folder should
> > request? which headers would you eliminate conditionally?
>
> I'd probably start with the references in case the user doesn't want his
> headers-view to be threaded, and fetch only t
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote: > On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote: > > Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit : > > > Without immediately writing to disk work, the download by itself will > > > consume around 120 MB of RAM, and will most likely fail due to network > > > timeouts and other such problems (it'll take a while, since Evolution > > > fetches a ridiculous large amount of headers for each message for > > > building its summary). > > > > > isn't the imap-features plugin's goal to reduce/customize the amount of > > downloaded headers ? Or is it that it's still not enough ? > > It improves the situation by setting your url-string to have the > "basic_headers" option. In the imap code of Camel, it will then ask for > less headers (but still way too much). if you set the option to "basic headers", it will only fetch the minimal set of headers required to show the message-list: "DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE " (actually, why is MIME-VERSION in there? it's useless) > > A major improvement it certainly isn't. it's not possible to do better w/o dropping features like message threading. In fact, the above minimalizing of header fetching already breaks the quick context-menu "vfolder on mailing-list" and "filter on mailing-list" features as well as making vfoldering on mailing-list oodles slower (if it even still works after disabling the headers) > > The best way is to ask for the ENVELOPE and the remaining info using the > normal BODY.PEEK method. Have you actually ever tested this theory? or did you just pull this out of your proverbial? You should note that Thunderbird does not use ENVELOPE, probably because they found it was LESS efficient to fetch the ENVELOPE + BODY.PEEK[HEADER.FIELDS (REFERENCES CONTENT-TYPE)] on many existing IMAP servers in the wild. Having myself tested this in the past, I don't recall it making much difference one way or the other. Sadly using ENVELOPE breaks on at least one proprietary IMAP server which occasionally likes to send back responses with NIL as each and every item, at least until a client has issued a BODY.PEEK fetch request. > It should be possible to specify per folder > which of the headers are to be fetched, to make it really efficient. how do you propose calculating the list of headers each folder should request? which headers would you eliminate conditionally? > > The imap4 implementation seems to have an ENVELOPE parser, so I guess > either it does it already or it will use ENVELOPE in future. it fetches: ENVELOPE BODY.PEEK[HEADER.FIELDS (Content-Type References In-Reply-To)] and optionally the mailing-list headers I believe it fetches IN-REPLY-TO (which is included in ENVELOPE) explicitly because some IMAP servers tried to be smart and parse the IN-REPLY-TO header for us and didn't handle embedded phrases which certain broken free-software mailers like to send. > > For a mobile device, that works over GPRS, you for example are usually > not interested (not at all) in the mailinglist specific headers. this is mobile-device specific tho, when I was implementing imap4 and people started trying to use it, it was their #1 complaint (which is why imap4 conditionally requests the mlist headers... tho that flag may be hard-coded to TRUE now, I'm not sure) > > It would also be possible to do it in multiple passes. For example get a > modest list of headers, and after that get more and more. but then you introduce a lot more complexity (e.g. scheduling such a fetch) slowness for the user (e.g. if he expects to be able to right-click and select "vfolder on mailing-list", he'd have to wait if the info had not yet been fetched... or even just selecting a mailing-list vfolder) keep in mind also that this is a one-time fetch, so while opening a folder for the first time might be slow (if you have 1000's of messages), future folder selections would take a much more reasonable amount of time to open (especially with CONDSTORE support which reduces the FLAGS sync requirements, which is where the real slowness is when opening a folder for most users) > > In any case, none of the current Evolution code implements consuming the > CONDSTORE capabilities of some modern IMAP servers (like MBox and > Cyrus). > > CONDSTORE is really going to make an enormous difference in bandwidth > consumption with large folders. That's because you only need to fetch > the flags of the changed messages to synchronise flags. yes, this would be nice to have... but as far as I'm aware, it is still only a draft standard (e.g. it could change). I would probably not be opposed to a CONDSTORE implementation making it into upstream camel, tho. > > Note that Tinymail's camel-lite implements all the needed solutions to > this bandwidth consumption problem. And that its code is, although a lot > of work because the Evolution maintainers didn
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-05-31 at 17:18 -0400, Jeffrey Stedfast wrote:
[snip]
> > Single namespace. It's all INBOX.folder.subfolder.
> > The one wrinkle is that in some cases 'folder' exists in the namespace,
> > but is not an actual box or folder (whatever the right term is) on the
> > server: INBOX.folder.subfolder is a real folder; INBOX.folder is not.
>
> I guess just a bug
>
I don't have a build environment anymore so I can't easily test this
patch, but perhaps i will fix your missing folder troubles.
Jeff
Index: ChangeLog
===
--- ChangeLog (revision 7792)
+++ ChangeLog (working copy)
@@ -1,5 +1,9 @@
2007-05-31 Jeffrey Stedfast <[EMAIL PROTECTED]>
+ * camel-imap4-store.c (imap4_build_folder_info): Add "ghost"
+ folder info's if needed in order to make sure the folder-info tree
+ is complete.
+
* camel-imap4-utils.c (camel_imap4_parse_flags_list): Handle
Junk/NonJunk flags.
Index: camel-imap4-store.c
===
--- camel-imap4-store.c (revision 7791)
+++ camel-imap4-store.c (working copy)
@@ -1169,7 +1169,85 @@
}
}
+static char *
+list_parent (camel_imap4_list_t *mbox)
+{
+ const char *d;
+
+ if (!(d = strrchr (mbox->name, mbox->delim)))
+ return NULL;
+
+ return g_strndup (mbox->name, d - mbox->name);
+}
+
+/* bloody glib... GPtrArray doesn't have an insert method */
static void
+array_insert (GPtrArray *array, int index, void *data)
+{
+ int i;
+
+ if ((index + 1) == array->len) {
+ /* special case, adding to the end of the array */
+ g_ptr_array_add (array, data);
+ return;
+ }
+
+ if (index >= array->len) {
+ /* special case, adding past the end of the array */
+ g_ptr_array_set_size (array, index + 1);
+ array->pdata[index] = data;
+ return;
+ }
+
+ g_ptr_array_set_size (array, array->len + 1);
+
+ /* shift all elements starting at @index 1 position to the right */
+ for (i = array->len - 2; i >= index; i--)
+ array->pdata[i + 1] = array->pdata[i];
+
+ array->pdata[index] = data;
+}
+
+static void
+list_add_ghosts (GPtrArray *array)
+{
+ camel_imap4_list_t *mbox;
+ GHashTable *list_hash;
+ char delim, *parent;
+ int i = 0;
+
+ list_hash = g_hash_table_new (g_str_hash, g_str_equal);
+
+ while (i < array->len) {
+ mbox = array->pdata[i];
+ if ((parent = list_parent (mbox))) {
+ if (!g_hash_table_lookup (list_hash, parent)) {
+/* ghost folder, insert a fake LIST info w/ a \NoSelect flag */
+delim = mbox->delim;
+mbox = g_new (camel_imap4_list_t, 1);
+mbox->flags = CAMEL_FOLDER_NOSELECT;
+mbox->name = parent;
+mbox->delim = delim;
+
+g_hash_table_insert (list_hash, parent, mbox);
+
+array_insert (array, i, mbox);
+continue;
+ } else {
+/* already exists */
+g_free (parent);
+ }
+ }
+
+ g_hash_table_insert (list_hash, mbox->name, mbox);
+
+ i++;
+ }
+
+ g_hash_table_destroy (list_hash);
+}
+
+static void
imap4_status (CamelStore *store, CamelFolderInfo *fi)
{
CamelIMAP4Engine *engine = ((CamelIMAP4Store *) store)->engine;
@@ -1269,6 +1347,7 @@
g_ptr_array_sort (array, (GCompareFunc) list_sort);
list_remove_duplicates (array);
+ list_add_ghosts (array);
url = camel_url_copy (engine->url);
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-05-31 at 11:38 -0700, Ross Boylan wrote: > On Thu, 2007-05-31 at 14:10 -0400, Jeffrey Stedfast wrote: > > On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote: > > > Hi. I've been getting into the code of evolution recently, and am > > > thinking of > > > doing a bit more to see if I can get it working OK for my situation. I > > > have > > > an IMAP mailbox which is very large, both in terms of folders (over 100) > > > and > > > messages (the largest folder has >300,000 messages; my INBOX has about > > > 22,000). > > > > the largest INBOX I've ever used was about ~100,000 messages, so you may > > get to have some fun :) > > > > > > > > None of the email clients I've tried cope with this very well. Since > > > I've > > > been using evo at work in a similar setup (cyrus server, though not quite > > > as > > > big), I thought it might be the best to try to tweak. The problems I've > > > had > > > so far involve setup activities rather than core functionaility. First, > > > evolution couldn't create the account (solved); second I've had problems > > > getting it to show all of my subfolders. > > > > are they in different namespaces? Current evo IMAP provider doesn't > > handle multiple namespaces :( > Single namespace. It's all INBOX.folder.subfolder. > The one wrinkle is that in some cases 'folder' exists in the namespace, > but is not an actual box or folder (whatever the right term is) on the > server: INBOX.folder.subfolder is a real folder; INBOX.folder is not. I guess just a bug [snip] > > > How do I find out which of the imap store's code I'm actually using? > > > > you are probably using the provider in > > evolution-data-server/camel/providers/imap > Is the other not loaded, or does it depend on which option I picked for the > server (I said IMAP4rev1). > ah, in that case you chose imap4 and not imap the imap provider is simply named "IMAP" in the drop-down menu in the account editor. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-05-31 at 13:38 -0700, Ross Boylan wrote: > On Thu, 2007-05-31 at 16:10 -0400, Matthew Barnes wrote: > > On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote: > > > What version to start with? I'm on Debian GNU/Linux, which currently has > > > evo > > > 2.6. I notice that's a bit dated (although I did see that a few months > > > ago > > > some of the Debian packagers were interested in making a more recent > > > version). I've been working from the Debian version. Does that version, > > > the > > > last stable release (from evo, not Debian), or svn head make the most > > > sense > > > to work from? (BTW, the one bug I fixed was one that was already fixed > > > post-2.6). > > > > FYI, Debian Unstable has Evolution 2.10. Might be easier to grab at > > least the 2.10 dependencies from there. You'll need to upgrade gtkhtml > > and likely also your GTK+ library stack to get 2.10 to build. > > > > Matthew Barnes > If I update GTK+ is that going to break other apps that use that > library? no, gtk maintains binary compat with older versions of the same major revision (2.x in this case) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote: > Hi. I've been getting into the code of evolution recently, and am thinking > of > doing a bit more to see if I can get it working OK for my situation. I have > an IMAP mailbox which is very large, both in terms of folders (over 100) and > messages (the largest folder has >300,000 messages; my INBOX has about > 22,000). the largest INBOX I've ever used was about ~100,000 messages, so you may get to have some fun :) > > None of the email clients I've tried cope with this very well. Since I've > been using evo at work in a similar setup (cyrus server, though not quite as > big), I thought it might be the best to try to tweak. The problems I've had > so far involve setup activities rather than core functionaility. First, > evolution couldn't create the account (solved); second I've had problems > getting it to show all of my subfolders. are they in different namespaces? Current evo IMAP provider doesn't handle multiple namespaces :( > > My narrow question is how to debug evolution. When I launched evolution in > gdb evolution (the GUI) came up, and then the debugger told me the process > had exited (though the GUI was up and running). I believe the initial > process does some kind of activation of the "real" process and then exits. sounds like you already had an instance of Evolution running (on another virtual desktop perhaps?) Evolution only allows one instance of itself to be running for the same user account... if you try to start a second instance, it signals the original instance to open a new window and then exits. > > I know I can attach to the second process, but I think the stuff I need to > see > happens at startup. So how can I get a debugger on the startup process of > the "real" evolution? should just be able to do gdb evolution (Note: I haven't debugged evolution in over a year since I've moved onto other projects, but that's how I always debugged it) > > I tried to search the archive, but the search function seems broken: it > searches everything, even though it says "search this list only." > > Also, evolution seems to have two presences on the web: a web site and a > wiki. > The developer stuff on the web site is old, and has no pointers to the newer > stuff that I could find. It would be good if it did. > > I have some broader questions too, if anyone has any comments on them. > > What version to start with? I'm on Debian GNU/Linux, which currently has evo > 2.6. I notice that's a bit dated (although I did see that a few months ago > some of the Debian packagers were interested in making a more recent > version). I've been working from the Debian version. Does that version, the > last stable release (from evo, not Debian), or svn head make the most sense > to work from? (BTW, the one bug I fixed was one that was already fixed > post-2.6). probably best to start with 2.10(.2) (or svn if you are brave) so as to avoid spending time fixing things that have already been fixed. > > Mission Impossible? Am I likely to get anywhere without spending lots of > time? I guess the answer to this is all relative... :) > I'm a professional software developer, but I'm not familiar with > GNOME, and this is clearly a complex application. > > Mission Advisable? If I get past the setup hurdles, is evolution likely to > be > able to handle the mail store I described? I think it'll be possible, there's lots of improvement that can be made to the current imap code :) > > How do I find out which of the imap store's code I'm actually using? you are probably using the provider in evolution-data-server/camel/providers/imap - imap4 is a project I started to replace the current imap provider and works fairly ok, but isn't quite complete (I forget all what it is missing since it's been a few years since I actively hacked on it - I think the main thing is cached search results?). This provider, like the current imap backend, suffers from being synchronous, but it is far better designed and much cleaner code to read. This backend also supports multiplenamespaces (tho it'd be better if the Camel API included multiple-namespace support, the way it works in imap4 is because all folders are listed from a toplevel namespace rather than from individual namespaces like it should). - imapp is an old attempt at making a pipelined imap provider, tho it is basically a dead-end at this point. - imapx is yet another attempt at replacing the current imap backend but depends on a lot of unfinished stuff in a development branch that has been abandoned for about 2 years now I think (the guy that had been working on that quit) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] X-Evolution: UUUUUUUU-FFFF - flags?
On Tue, 2007-05-29 at 17:04 +1000, Philip Rhoades wrote:
[snip]
>
>
> A 4 character hexdecimal value which represents the flags of the
> message.
>
> A typical example might be:
> X-Evolution: 002-0002
>
> This message is message number 2, and it is marked DELETED
> (CAMEL_MESSAGE_DELETED = 1<<1).
>
> and also:
>
> typedef enum _CamelMessageFlags {
> CAMEL_MESSAGE_ANSWERED = 1<<0,
> CAMEL_MESSAGE_DELETED = 1<<1,
> CAMEL_MESSAGE_DRAFT = 1<<2,
> CAMEL_MESSAGE_FLAGGED = 1<<3,
> CAMEL_MESSAGE_SEEN = 1<<4,
>
> CAMEL_MESSAGE_ATTACHMENTS = 1<<5,
> CAMEL_MESSAGE_ANSWERED_ALL = 1<<6,
> CAMEL_MESSAGE_JUNK = 1<<7,
> CAMEL_MESSAGE_SECURE = 1<<8,
>
> CAMEL_MESSAGE_FOLDER_FLAGGED = 1<<16,
>
> CAMEL_MESSAGE_JUNK_LEARN = 1<<30,
> CAMEL_MESSAGE_USER = 1<<31
> } CamelMessageFlags;
>
> #define CAMEL_MESSAGE_SYSTEM_MASK (0x << 16)
>
>
> but from this information (and some experimentation) I still can't work
> out all of these examples I have in my Inbox:
>
>
no flags set, aka "Unseen" (or "Unread" depending on how you prefer to
think of it)
> 0010
CAMEL_MESSAGE_SEEN
> 0011
CAMEL_MESSAGE_SEEN | CAMEL_MESSAGE_ANSWERED
> 0012
CAMEL_MESSAGE_SEEN | CAMEL_MESSAGE_DELETED
> 0013
CAMEL_MESSAGE_SEEN | CAMEL_MESSAGE_ANSWERED | CAMEL_MESSAGE_DELETED
> 0018
CAMEL_MESSAGE_SEEN | CAMEL_MESSAGE_FLAGGED
> 0019
CAMEL_MESSAGE_SEEN | CAMEL_MESSAGE_FLAGGED | CAMEL_MESSAGE_ANSWERED
Does that clear it up?
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposed fix for bug 311512
On Thu, 2007-04-26 at 07:50 +0100, Karl Relton wrote: > On Wed, 2007-04-25 at 09:48 -0400, Jeffrey Stedfast wrote: > > I'm not sure I'd call it get_filter_thread() because it's not getting a > > thread, all it is really doing is getting you a 'wait' id (and ugh, the > > new session_thread_wait() just busy-waits?) > > > > I think if this type of solution is really the "best" way of doing it, > > then I think it'd be better to just have a CamelFolder function > > (camel_folder_wait_filtering()? I dunno)that waits for the filtering > > operation to finish rather than providing a higher level with a wait id > > that it should never have to know or care about. > > > > Agreed - if this is the 'best way', I'll redo the patch as you suggest. > > > > > But better still would be to trap the "folder_changed" signal for > > folders that are currently in the process of filtering (CamelFolder > > already listens for this event in order to invoke the filtering iirc, so > > just stop the signal from propagating) and re-emit it later when > > filtering is complete (obviously with the updated changes). > > > > Yes - I had thought of this too. > > The trouble is with the current code its not quite so simple AFAIK. The > filtering that takes place is actually launched from the > folder_changed() function in camel-folder.c. In other words, it is > launched from the folder_changed event handler itself. Now I may be > wrong here, but my assumption is that both evo and e-d-s register event > handlers on this type of event - so that when such an event occurs code > in both evo and e-d-s is executed ... perhaps even in parallel (in their > own threads)? not completely correct... when you trigger an event on a CamelObject, it first fires the "prep" callback, which is what camel-folder.c:folder_changed() is (note that it returns bool) A prep event handler is the first handler called (event handlers are fired sequentially, in order of connection - /not/ in parallel) and gets to decide if the event propagates by returning TRUE (or FALSE if it should be blocked - that's how freeze/thaw works). > > If this is the case, then it is effectively too late to 'trap' the > event, because evo will already be processing it. all the event handler has to do is return FALSE to block other event handlers from firing :) > Thus (AFAICS) even if > camel is in a 'freeze' for folder_changed events, evo will still be > firing on every folder_changed occurence. only if folder_changed() returns TRUE - folder_changed() is what checks if the folder is in a freeze state, and if it is blocks further events from firing (by returning FALSE). You have da powah! > > One way to solve that would be to change things so that evo only fires > when camel folder_changed stuff has really done: effectively at the end > of a freeze AND filtering. That could be done by introducing a new event > and making evo trigger off that perhaps? unnecessary. all the tools are already available :) > > > > That would be a much cleaner way of doing it. > > > > Jeff > Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposed fix for bug 311512
I'm not sure I'd call it get_filter_thread() because it's not getting a
thread, all it is really doing is getting you a 'wait' id (and ugh, the
new session_thread_wait() just busy-waits?)
I think if this type of solution is really the "best" way of doing it,
then I think it'd be better to just have a CamelFolder function
(camel_folder_wait_filtering()? I dunno)that waits for the filtering
operation to finish rather than providing a higher level with a wait id
that it should never have to know or care about.
But better still would be to trap the "folder_changed" signal for
folders that are currently in the process of filtering (CamelFolder
already listens for this event in order to invoke the filtering iirc, so
just stop the signal from propagating) and re-emit it later when
filtering is complete (obviously with the updated changes).
That would be a much cleaner way of doing it.
Jeff
On Wed, 2007-04-25 at 08:13 +0100, Karl Relton wrote:
> Hi friends,
>
> Could anyone take a look at my proposed patches
> for fixing bug 311512. Srini has had a look, and noted the ABI breakage
> (see below). This was deliberate on my part - the only way to get
> newmail notification to take note of the results of a filter thread.
>
> Many thanks
> Karl
>
> On Fri, 2007-03-30 at 12:43 +0530, Srinivasa Ragavan wrote:
> > On Fri, 2007-03-30 at 07:51 +0100, Karl Relton wrote:
> > > Last week I posted two patches (one for eds, one for evo) on evo bugzill
> > > that I believe fix bug 311512.
> >
> > > --- camel-folder.h.1102007-03-20 16:57:40.0 +
> > > +++ camel-folder.h2007-03-20 16:50:34.0 +
> > > @@ -195,6 +195,7 @@ typedef struct {
> > > void (*freeze)(CamelFolder *folder);
> > > void (*thaw) (CamelFolder *folder);
> > > gboolean (*is_frozen) (CamelFolder *folder);
> > > + int (*get_filter_thread) (CamelFolder *folder);
> > > } CamelFolderClass;
> >
> > On first look, I noticed that your patch has introduced an ABI break in
> > CamelFolderClass.
> >
> > I'm sure that the mailer hackers would have a more closer look at it.
> >
> > Thanks for your friendly poke :-)
> >
> > -Srini.
> >
> > > f
> > > Could you take a look - any comments are welcome!
> > >
>
>
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Maintainership
On Thu, 2007-03-29 at 21:24 -0600, Hans Petter Jansson wrote: > On Thu, 2007-03-29 at 15:15 +0530, Harish Krishnaswamy wrote: > > > This mail is to announce that Srinivasa Ragavan (srag) is joining me > > to assume the responsibilites as maintainer of the Evolution project. > > > > [...] > > Congratulations, Srini! And a big thank you to Harish and the Evolution > team for your hard work and dedication to the project. The truth is, > with more than 7 years of development behind it, it's one of the best > mailers around. > +1 You've done a fantastic job with Evolution :) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?
On Thu, 2006-11-30 at 12:08 -0500, Matthew Barnes wrote: > On Thu, 2006-11-30 at 11:51 -0500, Jeffrey Stedfast wrote: > > wow, that came out totally wrong... > > > > using a single bit allows us to extend the structure with more bitfields > > w/o breaking ABI if we find we need to. > > > > it's akin to having: > > > > unsigned int sync_offline:1; > > unsigned int unused:31; > > I'm just curious, but what's the advantage of bitfields over just having > an integer field called "flags" and defining the individual flags as > enum values? The latter approach has all the advantages that Jeff > enumerated, but it also allows you to work with groups of flags at once > (e.g. masking, copying, etc.). Perhaps that's not relevant for this > particular case? in this particular case, it's unlikely that usage would be useful. > > Matthew Barnes > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Jeffrey Stedfast Desktop Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?
wow, that came out totally wrong...
using a single bit allows us to extend the structure with more bitfields
w/o breaking ABI if we find we need to.
it's akin to having:
unsigned int sync_offline:1;
unsigned int unused:31;
On Thu, 2006-11-30 at 11:41 -0500, Jeffrey Stedfast wrote:
> the idea is that we only need 1 bit as a boolean... if we declare it as
> a boolean now, then later if we discover we need more state, then we
> have to add a whole new boolean to avoid breaking ABI.
>
> In this fashion, we have 31 more bits available to us :)
>
> Jeff
>
> On Thu, 2006-11-30 at 09:43 +0100, Jules Colding wrote:
> > Hi,
> >
> > Is this really necessary?
> >
> > struct _CamelOfflineFolder {
> > CamelFolder parent_object;
> >
> > unsigned int sync_offline:1;
> > };
> >
> > Wouldn't it be much better/simpler/cleaner simply to do:
> >
> > struct _CamelOfflineFolder {
> > CamelFolder parent_object;
> >
> > gboolean sync_offline;
> > };
> >
> > ??
> >
--
Jeffrey Stedfast
Desktop Hacker - Novell, Inc.
[EMAIL PROTECTED] - www.novell.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
