Re: [Evolution-hackers] If an account changes, who regenerates the services?

2010-10-25 Thread Jeffrey Stedfast
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

2010-07-03 Thread Jeffrey Stedfast
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

2010-03-11 Thread Jeffrey Stedfast
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] Raw access to message

2010-03-11 Thread Jeffrey Stedfast
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] gcc 4.4 may be causing a number of bugs in Evolution

2010-02-02 Thread Jeffrey Stedfast
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


Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution

2010-02-02 Thread Jeffrey Stedfast
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] mail address validation

2010-01-21 Thread Jeffrey Stedfast
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 stdio.h
 #include camel/camel.h

 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] mail address validation

2010-01-21 Thread Jeffrey Stedfast
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] Moving from the single mbox file format for the local folders

2009-12-17 Thread Jeffrey Stedfast
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

2009-12-16 Thread Jeffrey Stedfast
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

2009-12-16 Thread Jeffrey Stedfast
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

2009-12-16 Thread Jeffrey Stedfast
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] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all

2009-01-06 Thread Jeffrey Stedfast
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


Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all

2009-01-06 Thread Jeffrey Stedfast
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] camel-folder-summary.c - 64bit-ness ...

2009-01-06 Thread Jeffrey Stedfast
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


[Evolution-hackers] unsubscribing to evolution-mail-maintainers

2008-12-19 Thread Jeffrey Stedfast
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

2008-09-01 Thread Jeffrey Stedfast
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...

2008-07-15 Thread Jeffrey Stedfast
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

2008-07-01 Thread Jeffrey Stedfast
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/revision date/ 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  number.
 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 implemented without changing anything in
 libecal. I could implement it as part of 

Re: [Evolution-hackers] Is there any APIs for fetching the GPG Key id from a CamelMimeMessage ?

2008-06-25 Thread Jeffrey Stedfast
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] Review a patch?

2008-05-22 Thread Jeffrey Stedfast
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?

2008-05-22 Thread Jeffrey Stedfast
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?

2008-05-21 Thread Jeffrey Stedfast
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


[Evolution-hackers] Camel Provider/Getv/Setv

2008-05-16 Thread Jeffrey Stedfast
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


Re: [Evolution-hackers] evolution build fails on em-folder-properties.c

2008-05-16 Thread Jeffrey Stedfast
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_range (G_MININT, 
 G_MAXINT, 1.0);
 +   gtk_spin_button_set_value ((GtkSpinButton *) w, 
 

[Evolution-hackers] mboxtool

2008-05-08 Thread Jeffrey Stedfast
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 config.h
#endif

#include stdio.h
#include stdlib.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include fcntl.h
#include errno.h

#include gmime/gmime.h

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, offset + info-msg_uid, GMIME_STREAM_SEEK_SET)) == -1)
break;
			
			if ((rv = g_mime_stream_printf (stream, X-Evolution: %08x-, i + 1)) == -1)
break;
			
			if ((rv = g_mime_stream_seek (stream, 0, GMIME_STREAM_SEEK_END

Re: [Evolution-hackers] Evolution doesnt recognise any mouse click events....PLZ HELP.......

2008-04-25 Thread Jeffrey Stedfast
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] Largefile support

2008-04-07 Thread Jeffrey Stedfast

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] SVN head build fails 'O_LARGEFILE' undeclared (first use in this function)

2008-04-07 Thread Jeffrey Stedfast

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] Loading really large E-mails on devices with not enough Vm

2008-01-27 Thread Jeffrey Stedfast

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

2008-01-26 Thread Jeffrey Stedfast
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] Loading really large E-mails on devices with not enough Vm

2008-01-26 Thread Jeffrey Stedfast
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

2008-01-26 Thread Jeffrey Stedfast
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(appending o/p data: %d: %.*s\n, len, len, buf));
-		g_byte_array_append (buffer, (guint8 *) buf, len);
+		if (buffer != NULL) {
+			d(printf(appending o/p data: %d: %.*s\n, len, len, buf));
+			g_byte_array_append (buffer, (guint8 *) buf, len);
+		}
 	}
-
-	d(printf(message part kept in memory!\n));
-
-	mem = camel_stream_mem_new_with_byte_array (buffer

Re: [Evolution-hackers] Diary replaying on IMAP accounts

2008-01-21 Thread Jeffrey Stedfast

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

2008-01-19 Thread Jeffrey Stedfast
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 FALSE;
   }
 
   return TRUE;
 }
 
 
 
 -- 
 Philip Van Hoof, freelance software developer
 home: me at pvanhoof dot be 
 gnome: pvanhoof at gnome dot org 
 http://pvanhoof.be/blog
 

Re: [Evolution-hackers] improved rfc2047 decode patch

2007-12-27 Thread Jeffrey Stedfast

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?any-encoded-text?==?gb2312?b?any-encoded-text?=
   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

2007-12-27 Thread Jeffrey Stedfast
: 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?any-encoded-text?==?gb2312?b?any-encoded-text?=
 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

2007-12-26 Thread Jeffrey Stedfast

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?any-encoded-text?==?gb2312?b?any-encoded-text?=
 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] [patch] fixed incorrect rfc2047 decode for CJKheader

2007-12-25 Thread Jeffrey Stedfast

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

2007-12-25 Thread Jeffrey Stedfast
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=5souce=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


[Evolution-hackers] improved rfc2047 decode patch

2007-12-25 Thread Jeffrey Stedfast
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[4] = { UTF-8, NULL, NULL, NULL };
+	size_t inleft, outleft, 

Re: [Evolution-hackers] improved rfc2047 decode patch

2007-12-25 Thread Jeffrey Stedfast
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


Re: [Evolution-hackers] [patch] fixed incorrect rfc2047 decode for CJK header

2007-12-24 Thread Jeffrey Stedfast
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=5souce=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

2007-12-02 Thread Jeffrey Stedfast
$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)

2007-10-29 Thread Jeffrey Stedfast
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

2007-10-26 Thread Jeffrey Stedfast
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=97895action=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

2007-10-25 Thread Jeffrey Stedfast
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

2007-10-25 Thread Jeffrey Stedfast

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] Let the porting begin

2007-10-24 Thread Jeffrey Stedfast
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

2007-10-11 Thread Jeffrey Stedfast
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

2007-10-11 Thread Jeffrey Stedfast
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] Copyright of Camel's individual source files

2007-10-09 Thread Jeffrey Stedfast
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] Copyright of Camel's individual source files

2007-10-09 Thread Jeffrey Stedfast
(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

2007-10-09 Thread Jeffrey Stedfast
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

2007-10-09 Thread Jeffrey Stedfast
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] Let's clean up dead files in Subversion trunk

2007-09-21 Thread Jeffrey Stedfast
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

2007-06-25 Thread Jeffrey Stedfast
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] EDS: Trying to implement expunge function in camel-spool-folder.c

2007-06-25 Thread Jeffrey Stedfast
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] Introduction and Questions

2007-06-11 Thread Jeffrey Stedfast
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)
  
  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.
 This part of the camel API is not syncronous, right?

in so much as doing camel_operation_cancel() returning doesn't mean that
the other thread has stopped, correct. Basically it just means that
you've sent a command along a pipe to the thread to cancel at its
earliest convenience.

  
   
   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.
 Why was camel separated out at all?

good model/view split :) you

Re: [Evolution-hackers] Camel Data Cache mechanism

2007-06-11 Thread Jeffrey Stedfast
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

2007-06-10 Thread Jeffrey Stedfast
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

2007-06-09 Thread Jeffrey Stedfast
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

2007-06-08 Thread Jeffrey Stedfast
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 the sequence number plus the
 references header the first time threaded is enabled on that folder and
 after that (while its enabled) for each summary-item update too.
 
 A lot mobile devices's screens are simply not suitable for threaded view
 anyway: introduces way to much wasted white space. Why fetch this
 information and waste the user's GPRS bandwidth and therefore often his
 money too? (for a lot people, GPRS bandwidth costs money per downloaded
 megabyte)
 
 In case the From is not displayed, there's

Re: [Evolution-hackers] Introduction and Questions

2007-06-08 Thread Jeffrey Stedfast
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

2007-06-08 Thread Jeffrey Stedfast
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

2007-06-08 Thread Jeffrey Stedfast
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 you aren't able to
request a partial thread-model based on view row indexes (which would be
ideal)

 
 Though I've mostly focused on responsiveness, the index the whole
 folder strategy also impacts bandwidth (as Philip pointed out) and
 local disk useage.

disk usage isn't that much, it's something like 2% of the size of the
mailbox.

also, unless you want to repeatedly request the summary info from the
server each session, then you need to cache it. You also need to cache
it for disconnected operation.

Mobile-device users might not care to have this, but a desktop client
requires it.

That said, Camel is pluggable... someone could easily write a
mobile-imap provider that works the way tnymail needs it to work.

Jeff

Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread Jeffrey Stedfast
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't seem interested at the
 time it was happening, definitely 

Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Jeffrey Stedfast
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] Introduction and Questions

2007-05-31 Thread Jeffrey Stedfast
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

2007-05-31 Thread Jeffrey Stedfast
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] X-Evolution: UUUUUUUU-FFFF - flags?

2007-05-29 Thread Jeffrey Stedfast
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 = 11).
 
 and also:
 
 typedef enum _CamelMessageFlags {
 CAMEL_MESSAGE_ANSWERED = 10,
 CAMEL_MESSAGE_DELETED = 11,
 CAMEL_MESSAGE_DRAFT = 12,
 CAMEL_MESSAGE_FLAGGED = 13,
 CAMEL_MESSAGE_SEEN = 14,
 
 CAMEL_MESSAGE_ATTACHMENTS = 15,
 CAMEL_MESSAGE_ANSWERED_ALL = 16,
 CAMEL_MESSAGE_JUNK = 17,
 CAMEL_MESSAGE_SECURE = 18,
 
 CAMEL_MESSAGE_FOLDER_FLAGGED = 116,
 
 CAMEL_MESSAGE_JUNK_LEARN = 130,
 CAMEL_MESSAGE_USER = 131
 } 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

2007-04-26 Thread Jeffrey Stedfast
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

2007-04-25 Thread Jeffrey Stedfast
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] Why a bitfield in CamelOfflineFolder?

2006-11-30 Thread Jeffrey Stedfast
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


Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?

2006-11-30 Thread Jeffrey Stedfast
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


Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?

2006-11-30 Thread Jeffrey Stedfast
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] GStringChunk - not all it's cracked up to be.

2006-11-06 Thread Jeffrey Stedfast
On Fri, 2006-11-03 at 20:00 +, Ross Burton wrote:
 On Fri, 2006-11-03 at 14:26 -0500, Jeffrey Stedfast wrote:
  With these new patches coming in pushing the idea of moving to a
  GStringChunk here and there, at first it all sounds well and good, but
  then I looked at the source code to GStringChunk because I had a feeling
  of how it was implemented and based on that feling, had some bad
  feelings about how it handled situations that would be extremely likely
  to cause a more bloated usage of memory than aught be the case.
 
 Would it be reasonable to hack on GStringChunk stealing relevant bits of
 code from EDS, instead of duplicating similar functionality?

I suppose, the problem is that the GStringChunk API is kind of lacking
so retrofitting a better implementation into the same API might be
difficult.

   If a patch
 comes with and this is why it's a vast improvement, it will probably
 get accepted.

No doubt... one could easily improve GStringChunk significantly just
by keeping track of how much free space remains in each block. The thing
is that even with that approach, you can still end up wasting a lot of
space if the most string lengths are just slightly larger than half the
size of each block size... and if you choose a block size shorter than
the typical length, then you are simply degenerating into g_strduping
each string AND still getting penalised by tracking overhead.

 
 Ross
-- 
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] [PATCH 3/3] Add some missing includes

2006-08-15 Thread Jeffrey Stedfast
the original idea was to speed up compile time

On Tue, 2006-08-15 at 08:50 +, Tor Lillqvist wrote:
 må 2006-08-14 klockan 19:58 -0400 skrev Pavel Roskin:
  From: Pavel Roskin [EMAIL PROTECTED]
 
  --- a/widgets/misc/e-icon-entry.c
  +++ b/widgets/misc/e-icon-entry.c
  @@ -39,6 +39,8 @@ #include e-icon-entry.h
   #include gtk/gtkentry.h
   #include gtk/gtkbox.h
   #include gtk/gtkhbox.h
  +#include gtk/gtkeventbox.h
  +#include gtk/gtkimage.h
 
 Isn't the correct thing here to just include gtk/gtk.h and not attempt
 to hand-pick individual gtk headers?
 
 --tml
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution 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] [PATCH 3/3] Add some missing includes

2006-08-15 Thread Jeffrey Stedfast
Zucchi did timings a while back and found it to be worth it *shrug*

I don't have the timings on me tho, so I have no idea what kind of
difference it made.

On Tue, 2006-08-15 at 15:20 +, Tor Lillqvist wrote:
 ti 2006-08-15 klockan 10:18 -0400 skrev Jeffrey Stedfast:
  the original idea was to speed up compile time
 
 Sure, I can guess that, but is it worth it? Some timings would be
 interesting, but on the other hand, it can't be worth spending time on
 doing such timings...
 
 --tml
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution 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] How to change the accountname?

2006-08-14 Thread Jeffrey Stedfast
No, there aren't any hooks that camel can use to do that.

Jeff

On Mon, 2006-08-14 at 10:29 +0200, Smartuser wrote:
 Hello,
 
 I've seen it is possible to change the account name as a user.
 But is it possible to create an accountname from the camel-provider?
 or at least do the user a proposal for it? (auto fill in)
 
 Any help would be appreciated.
 
 Kind regards,
 Serjan Pruis
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED]  - www.novell.com

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] mmap patch

2006-07-19 Thread Jeffrey Stedfast
Well, I figured out why you're getting alignment problems... you're
using int* pointers to decode stuff. You need to use a char*

Secondly, your code is just really gross:

- Why do you have a filepos pointer? it's completely unnecessary.

- Why do you use a ptr32 thing? That's gross. There are far cleaner ways
of doing this... it's also the source of your alignment problems.

- Why do you have ::needs_free and ::uid_needs_free? Please find another
way to do this. This is a horrible hack.

Attached you'll find the beginnings of a much cleaner implementation of
the mmap approach.



-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED]  - www.novell.com
? camel-gpg-context.c.gpg
? camel-mime-tables.c
? camel_folder_summary_with_mmap_fixes11.txt
? const-charset-map.patch
? mmap.patch
? pgp-filter.patch
? pstring.patch
? providers/imap4/272058.patch
? providers/imap4/imap4-sockopt.patch
? providers/local/largefile-mbox.patch
? providers/pop3/pop3-folder.c
Index: camel-file-utils.c
===
RCS file: /cvs/gnome/evolution-data-server/camel/camel-file-utils.c,v
retrieving revision 1.17
diff -u -r1.17 camel-file-utils.c
--- camel-file-utils.c	2 Jun 2006 00:52:29 -	1.17
+++ camel-file-utils.c	19 Jul 2006 20:32:13 -
@@ -262,18 +262,18 @@
 int
 camel_file_util_encode_string (FILE *out, const char *str)
 {
-	register int len;
-
-	if (str == NULL)
-		return camel_file_util_encode_uint32 (out, 1);
+	size_t len;
 	
-	if ((len = strlen (str))  65536)
-		len = 65536;
+	if (str == NULL)
+		return camel_file_util_encode_size_t (out, 0);
 	
-	if (camel_file_util_encode_uint32 (out, len+1) == -1)
+	len = strlen (str);
+	if (camel_file_util_encode_size_t (out, len + 1) == -1)
 		return -1;
-	if (len == 0 || fwrite (str, len, 1, out) == 1)
+	
+	if (fwrite (str, len + 1, 1, out) == 1)
 		return 0;
+	
 	return -1;
 }
 
@@ -290,29 +290,317 @@
 int
 camel_file_util_decode_string (FILE *in, char **str)
 {
-	guint32 len;
-	register char *ret;
-
-	if (camel_file_util_decode_uint32 (in, len) == -1) {
+	size_t len;
+	
+	if (camel_file_util_decode_size_t (in, len) == -1) {
 		*str = NULL;
 		return -1;
 	}
-
-	len--;
-	if (len  65536) {
+	
+	if (len == 0) {
+		*str = NULL;
+		return 0;
+	}
+	
+	if (!(*str = g_try_malloc (len))) {
 		*str = NULL;
 		return -1;
 	}
-
-	ret = g_malloc (len+1);
-	if (len  0  fread (ret, len, 1, in) != 1) {
-		g_free (ret);
+	
+	if (fread (*str, len, 1, in) != 1) {
+		g_free (*str);
 		*str = NULL;
 		return -1;
 	}
+	
+	return 0;
+}
+
+
+/**
+ * camel_mmap_util_encode_uint32:
+ * @out: file to output to
+ * @value: value to output
+ * 
+ * Utility function to save an uint32 to a file.
+ * 
+ * Return value: 0 on success, -1 on error.
+ **/
+int
+camel_mmap_util_encode_uint32 (char **out, guint32 value)
+{
+	char *outptr = *out;
+	unsigned char c;
+	int i;
+	
+	for (i = 28; i  0; i -= 7) {
+		if (value = (1  i)) {
+			c = (value  i)  0x7f;
+			*outptr++ = c;
+		}
+	}
+	
+	c = value  0x7f;
+	*outptr++ = c | 0x80;
+	
+	*out = outptr;
+	
+	return 0;
+}
+
+
+/**
+ * camel_mmap_util_decode_uint32:
+ * @in: file to read from
+ * @dest: pointer to a variable to store the value in
+ * 
+ * Retrieve an encoded uint32 from a file.
+ * 
+ * Return value: 0 on success, -1 on error.  @*dest will contain the
+ * decoded value.
+ **/
+int
+camel_mmap_util_decode_uint32 (const char **in, guint32 *dest)
+{
+	const char *inptr = *in;
+guint32 value = 0;
+	unsigned char v;
+	
+/* until we get the last byte, keep decoding 7 bits at a time */
+	while (((v = *inptr++)  0x80) == 0) {
+		value |= v;
+		value = 7;
+	}
+	
+	*dest = value | (v  0x7f);
+	*in = inptr;
+	
+return 0;
+}
+
+
+/**
+ * camel_mmap_util_encode_fixed_int32:
+ * @out: file to output to
+ * @value: value to output
+ * 
+ * Encode a gint32, performing no compression, but converting
+ * to network order.
+ * 
+ * Return value: 0 on success, -1 on error.
+ **/
+int
+camel_mmap_util_encode_fixed_int32 (char **out, gint32 value)
+{
+	gint32 save;
+	
+	save = GINT32_TO_LE (value);
+	memcpy (*out, save, sizeof (gint32));
+	*out = *out + sizeof (gint32);
+	
+	return 0;
+}
+
+
+/**
+ * camel_mmap_util_decode_fixed_int32:
+ * @in: file to read from
+ * @dest: pointer to a variable to store the value in
+ * 
+ * Retrieve a gint32.
+ * 
+ * Return value: 0 on success, -1 on error.
+ **/
+int
+camel_mmap_util_decode_fixed_int32 (const char **in, gint32 *dest)
+{
+	const char *inptr = *in;
+	gint32 value = 0;
+	int i;
+	
+	for (i = 0; i  sizeof (guint32); i++, inptr++, value = 8)
+		value |= *inptr;
+	
+	*dest = GUINT32_FROM_LE (value);
+	*in = inptr;
+	
+	return 0;
+}
+
+#define MMAP_ENCODE_T(type)		\
+int	\
+camel_mmap_util_encode_##type(char **out, type value)			\
+{	\
+	type save;			\
+	\			
+	switch (sizeof (type)) {	\
+	case 4:\
+		save = GUINT32_TO_LE (value);\
+		break;			\
+	case 8:\
+		save

Re: [Evolution-hackers] The fixes11 mmap patch doesn't respect data alignment on some architectures

2006-07-14 Thread Jeffrey Stedfast
ah, you're going to have to pad strings and possibly other stuff.

Jeff

On Fri, 2006-07-14 at 19:23 +0200, Philip Van Hoof wrote:
 While the x86 handles unaligned access, ARM doesn't. The patch will not
 work on architectures that don't handle unaligned access.
 
 I will try to fix it, but I don't have a lot experience in this field.
 
-- 
Jeffrey Stedfast
Evolution 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] [evolution-patches] Avoiding a strdup in camel-folder-summar.c

2006-07-12 Thread Jeffrey Stedfast
On Wed, 2006-07-12 at 02:27 +0530, Ritesh Khadgaray wrote:
 On Tue, 2006-07-11 at 09:28 -0400, Chris Toshok wrote:
  No opinion on the rest of the patch, but this:
  
   +static void
   +free_token (gchar *token)
   +{
   +   gint i=0;
   +   gboolean no=FALSE;
   +
   +   for (i=0; (i  tokens_len); i++)
   +   {
   +   if (tokens[i] == token)
   +   no = TRUE;
   +   }
   +
   +   if (!no)
   +   g_free (token);
   +}
   + 
  
  is more efficient as:
  
  static void
  free_token (gchar *token)
  {
  gint i;
  
  for (i = 0; i  tokens_len; i ++)
  if (tokens[i] == token)
  return;
 
 out of curiosity, the first patch reads through the list
 and this patch, return if any one of the token is equal, anf not any
 following it.
 
 Would the below not be better ?
 
   for (i = 0; i  tokens_len; i ++)
   if (tokens[i] == token)
   break;
 
 

no, because you'd segfault trying to g_free() a static string.

The point of the code Toshok wrote was to no-op if the string was static
and to g_free() it if not.

Jeff

-- 
Jeffrey Stedfast
Evolution 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] Camel mmap summary ideas, proposal for a meeting

2006-07-12 Thread Jeffrey Stedfast
There's a couple problems that I can think of that will need to be
solved in order for mmap to work (at least for Evolution, altho at least
a few of the problems also apply to tnymail)

1. (Evolution only?) fd usage will easily max out on systems like
Solaris and/or installations where the user has a large number of
folders. Each mmap'd file requires a persistantly open file descriptor,
which, especially combined with vFolders, will be difficult to keep
under the system threshold.

tnymail solves this by never allowing more than a single folder to be
opened, but Evolution can't enforce that quite as easily. Even with
the ::open()/::close() idea I proposed a few years ago (or hacking
Evolution to try and do what tnymail does even), vFolders will still be
problematic because they keep all of their source folders opened
(mmap'd) so that the summary info is available.


2. As pvanhoof has discovered, when new messages arrive in an opened
folder, the summary info is just added to the array as malloc'd objects
(well, structs) and are not immediately written to disc.

While, yes, the simple solution is to do what pvanhoof proposes: write
those entries to disc and then re-mmap the file - this is kinda gross
and as Varadhan has pointed out, is not as efficient because we'd have
to reparse the entire summary file again. We also would have the
following problems:

  a. remapping the file also means that all string pointers currently in
use by the application become invalid.

  b. to fix this, you'd need to emit a folder_changed signal letting the
application know that all of the original objects were removed and
replaced by a new set meaning that the message-list would be required to
re-build each time anything changed which is less than ideal. (okay,
yes, I believe it currently mostly does this already because of some
problems with incrememntally adding stuff to ETable but it means that
this problem can NEVER be fixed if we go the mmap route). It would also
mean that those MessageInfo objects wouldn't persist through
folder_changed events which would suck.

  c. you'd also need to sync any changes to flags/tags to disc before
you started appending the new message info's so that you don't lose any
data (this isn't really a problem, just listing it here so people don't
overlook this).


It also seems to me that if we were really going to be serious about
using mmap as a real solution (and not just a hack), we'd have to
redesign the summary files to group all the string data together to try
and keep strings in contiguous pages to keep page swapping to a minimum.
The current file layout is terribly inefficient for this.

-- 
Jeffrey Stedfast
Evolution 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] Camel mmap summary ideas, proposal for a meeting

2006-07-12 Thread Jeffrey Stedfast
On Wed, 2006-07-12 at 20:05 +0200, Philip Van Hoof wrote:
 On Wed, 2006-07-12 at 13:34 -0400, Jeffrey Stedfast wrote:
 
[snip]
  It also seems to me that if we were really going to be serious about
  using mmap as a real solution (and not just a hack), we'd have to
  redesign the summary files to group all the string data together to try
  and keep strings in contiguous pages to keep page swapping to a minimum.
  The current file layout is terribly inefficient for this.
 
 I very much agree with this. The file format can be much improved
 indeed. Compressing (not in the context of ZIP compressing, but by
 avoiding redundant information) can for example be implemented in such a
 way that the file gets stored without any redundant information.
 
 -- Oh by the way. There's a huge amount of Re:  strings in my memory
 at this moment. We can probably improve that too ;-) --

Yea, I've been wanting to overlap strings in such a way as to allow Re:
my subject string and my subject string to re-use the same memory.
Not sure the complexity of this would be worth the (likely very small)
memory savings tho

but at worst, using a single strtab would be nice even if Re: ... and
... didn't overlap.

-- 
Jeffrey Stedfast
Evolution 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] [evolution-patches] Fix for agressive memory segmentation

2006-07-06 Thread Jeffrey Stedfast
For some strange reason I thought the pstring stuff already did that,
oops. I guess I was thinking of similar code I wrote a few years back
for another project...

This patch does it the way I had done it in another project of mine

On Thu, 2006-07-06 at 20:31 +0200, Philip Van Hoof wrote:
 Camel makes some aggressive memory segmentation happen when loading
 the folder summary.
 
 This fixes that.
 
 This is NOT yet the mmap() idea. That will come later.
 
 
 ___
 Evolution-patches mailing list
 [EMAIL PROTECTED]
 http://mail.gnome.org/mailman/listinfo/evolution-patches
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED]  - www.novell.com
? 340717.patch
? camel-mime-tables.c
? pstring.patch
? providers/imap/camel-imap-private.h
? providers/local/mbox-repair.patch
? providers/smtp/336035.patch
Index: ChangeLog
===
RCS file: /cvs/gnome/evolution-data-server/camel/ChangeLog,v
retrieving revision 1.2526.2.10
diff -u -r1.2526.2.10 ChangeLog
--- ChangeLog	15 Jun 2006 20:51:50 -	1.2526.2.10
+++ ChangeLog	6 Jul 2006 19:18:34 -
@@ -1,3 +1,18 @@
+2006-07-06  Jeffrey Stedfast  [EMAIL PROTECTED]
+
+	* camel-string-utils.c (camel_pstring_add): New function that now
+	holds the main logic of the old camel_pstring_strdup function. If
+	'own' is TRUE, re-use the memory if the string doesn't already
+	exist and free it otherwise. If FALSE, strdup the value if it
+	doesn't already exist.
+	(camel_pstring_strdup): Calls camel_pstring_add() with 'own' as
+	FALSE.
+
+	* camel-folder-summary.c (message_info_new_from_header): Use
+	camel_pstring_add instead of camel_pstring_strdup here to prevent
+	unnecessary strdup/freeing.
+	(message_info_load): Same.
+
 2006-06-15  Tor Lillqvist  [EMAIL PROTECTED]
 
 	* camel.c (camel_init): On Win32, NSS wants the directory name in
Index: camel-folder-summary.c
===
RCS file: /cvs/gnome/evolution-data-server/camel/camel-folder-summary.c,v
retrieving revision 1.147.2.2
diff -u -r1.147.2.2 camel-folder-summary.c
--- camel-folder-summary.c	13 Apr 2006 19:57:55 -	1.147.2.2
+++ camel-folder-summary.c	6 Jul 2006 19:18:34 -
@@ -1624,19 +1624,13 @@
 
 	if (ct)
 		camel_content_type_unref(ct);
-
-	mi-subject = camel_pstring_strdup(subject);
-	mi-from = camel_pstring_strdup(from);
-	mi-to = camel_pstring_strdup(to);
-	mi-cc = camel_pstring_strdup(cc);
-	mi-mlist = camel_pstring_strdup(mlist);
-
-	g_free(subject);
-	g_free(from);
-	g_free(to);
-	g_free(cc);
-	g_free(mlist);
-
+	
+	mi-subject = camel_pstring_add (subject, TRUE);
+	mi-from = camel_pstring_add (from, TRUE);
+	mi-to = camel_pstring_add (to, TRUE);
+	mi-cc = camel_pstring_add (cc, TRUE);
+	mi-mlist = camel_pstring_add (mlist, TRUE);
+	
 	mi-user_flags = NULL;
 	mi-user_tags = NULL;
 	mi-date_sent = camel_header_decode_date(camel_header_raw_find(h, date, NULL), NULL);
@@ -1709,20 +1703,14 @@
 	camel_file_util_decode_string(in, to);
 	camel_file_util_decode_string(in, cc);
 	camel_file_util_decode_string(in, mlist);
-
+	
 	mi-uid = uid;
-	mi-subject = camel_pstring_strdup(subject);
-	mi-from = camel_pstring_strdup(from);
-	mi-to = camel_pstring_strdup(to);
-	mi-cc = camel_pstring_strdup(cc);
-	mi-mlist = camel_pstring_strdup(mlist);
-
-	g_free(subject);
-	g_free(from);
-	g_free(to);
-	g_free(cc);
-	g_free(mlist);
-
+	mi-subject = camel_pstring_add (subject, TRUE);
+	mi-from = camel_pstring_add (from, TRUE);
+	mi-to = camel_pstring_add (to, TRUE);
+	mi-cc = camel_pstring_add (cc, TRUE);
+	mi-mlist = camel_pstring_add (mlist, TRUE);
+	
 	mi-content = NULL;
 
 	camel_file_util_decode_fixed_int32(in, mi-message_id.id.part.hi);
Index: camel-string-utils.c
===
RCS file: /cvs/gnome/evolution-data-server/camel/camel-string-utils.c,v
retrieving revision 1.5
diff -u -r1.5 camel-string-utils.c
--- camel-string-utils.c	15 Sep 2005 17:35:45 -	1.5
+++ camel-string-utils.c	6 Jul 2006 19:18:34 -
@@ -146,46 +146,72 @@
 static GHashTable *pstring_table = NULL;
 
 /**
- * camel_pstring_strdup:
- * @s: String to copy.
- * 
- * Create a new pooled string entry for the string @s.  A pooled
- * string is a table where common strings are uniquified to the same
- * pointer value.  They are also refcounted, so freed when no longer
- * in use.  In a thread-safe manner.
- * 
+ * camel_pstring_add:
+ * @str: string to add to the string pool
+ * @own: whether the string pool will own the memory pointed to by @s if @str is not yet in the pool
+ *
+ * Add the string to the pool.
+ *
  * The NULL and empty strings are special cased to constant values.
  *
  * Return value: A pointer to an equivalent string of @s.  Use
  * camel_pstring_free() when it is no longer needed.
  **/
-const char *camel_pstring_strdup(const char *s)
+const char *
+camel_pstring_add (char *str, gboolean own)
 {
-	char *p

Re: [Evolution-hackers] [evolution-patches] Fix for agressive memory segmentation

2006-07-06 Thread Jeffrey Stedfast
On Thu, 2006-07-06 at 21:32 +0200, Philip Van Hoof wrote:
 On Thu, 2006-07-06 at 15:18 -0400, Jeffrey Stedfast wrote:
  For some strange reason I thought the pstring stuff already did that,
  oops. I guess I was thinking of similar code I wrote a few years back
  for another project...
  
  This patch does it the way I had done it in another project of mine
 
 Yours looks a little bit more clean in naming and stuff like that. It
 probably does more or less the same? So I'd say commit one of the two?

yea, it's basically the same as what you did

 
 Mine made some significant differences when running it with valgrind. It
 was also a little bit faster in cachegrind (probably because there's
 less malloc()'s and free()'s happening).
 
 I'm still committed to the mmap() idea. Although I don't know for sure
 keeping folder-count amount of file descriptors open is a very good
 idea. I know the disk-summary branch would help a lot here. Regretfully
 that one isn't yet finished ;-).
 
 However. In tinymail I open and close folders much more quickly (each
 time a folder becomes inactive, I close it). Therefore I'm almost
 certain that for tinmails case the mmap() idea is going to significantly
 improve the situation for larger folders. I might introduce a compil-
 ation switch at the configure script.
 
 I wonder, would such a patch (in case it's clean and doesn't harm
 Evolution more than that Evolution would gain from it yadi yada) get
 upstream? The patch would definitely bump the version number of the
 summary file from 13 to 14. It would add a '\0' at the end of each
 string in the file, and it will add one to the length-bytes in front of
 the strings .. also in the file (which is forward compatible, so going
 back to an older Evolution version will work with the same summary
 files).

it's not that invasive, I guess... so I don't think I'd mind.

 
 
-- 
Jeffrey Stedfast
Evolution 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] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-19 Thread Jeffrey Stedfast
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is that in the idle cb, there may still be a race? Even
if not, tho, I feel it would be cleaner to unregister in a ::destroy()
if that's a possibility.

Jeff

On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
 lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
 
  If my analysis is correct, this means that attempting to do a CORBA
  object unregistration in the GObject finalize method is too late, isn't
  it?
 
 I tested by applying this simple patch to e-shell.c, moving the
 bonobo_activation_active_server_unregister() call from impl_finalize()
 to notify_no_windows_left_idle_cb():
 
 Index: shell/e-shell.c
 ===
 RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
 retrieving revision 1.272
 diff -p -u -r1.272 e-shell.c
 --- shell/e-shell.c   30 Jan 2006 11:49:53 -  1.272
 +++ shell/e-shell.c   16 Jun 2006 23:17:50 -
 @@ -360,13 +360,18 @@ static gboolean
  notify_no_windows_left_idle_cb (void *data)
  {
   EShell *shell;
 + EShellPrivate *priv;
  
   shell = E_SHELL (data);
 + priv = shell-priv;
  
   set_interactive (shell, FALSE);
  
   g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
  
 + if (priv-iid != NULL)
 + bonobo_activation_active_server_unregister (priv-iid,
 + 
 bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
   bonobo_object_unref (BONOBO_OBJECT (shell));
  
   return FALSE;
 @@ -467,10 +472,6 @@ impl_finalize (GObject *object)
  
   shell = E_SHELL (object);
   priv = shell-priv;
 -
 - if (priv-iid != NULL)
 - bonobo_activation_active_server_unregister (priv-iid,
 - 
 bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
  
   e_free_string_list (priv-crash_type_names);
  
 And lo and behold, it works! Now the ESHell gets unregistered, and when
 starting Evolution again it manages to register its EShell and contact
 the already running e-d-s etc.
 
 OK to apply this patch to HEAD and stable? ChangeLog entry:
 
 2006-06-17  Tor Lillqvist  [EMAIL PROTECTED]
 
   * e-shell.c (impl_finalize): Don't call
   bonobo_activation_active_server_unregister() here, it's too late,
   the EShell Bonobo object has already been deactivated and its
   associated CORBA object is NULL.
   (notify_no_windows_left_idle_cb): Instead, call
   bonobo_activation_active_server_unregister() here, when the EShell
   Bonobo object is still fully active.
 
 
 I should still of course also investigate why the other (unknown)
 mechanism which causes unregistration to happen anyway on Unix doesn't
 work on Windows...
 
 --tml
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution 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] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-19 Thread Jeffrey Stedfast
ah, okay.

Jeff

On Mon, 2006-06-19 at 17:03 +0300, Tor Lillqvist wrote:
 må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast:
  Is there a ::destroy() method on the EShell object (like GtkWidgets)?
  Perhaps it would be better to unregister there rather than in an idle
  cb? My concern is that in the idle cb, there may still be a race? 
 
 Nah... The impl_finalize() where the unregistration is currently done
 (but doesn't work) is called from the same
 notify_no_windows_left_idle_cb() function (through
 bonobo_object_unref()).
 
 --tml
 
 
-- 
Jeffrey Stedfast
Evolution 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] Help request: Mime v1.0 from char* to CamelMimeMessage*

2006-06-09 Thread Jeffrey Stedfast
On Fri, 2006-06-09 at 11:24 +0200, Smartuser wrote:
 This is some extra information on my previous message.
 - Help request: Mime v1.0 from char* to CamelMimeMessage*
 
 I've tried the following code to put the char* (containing the message) in a 
 stream. And then convert it to a message. But this dousnot work this way I 
 guess what am I doing wrong?
 
 
 CamelStream *stream = NULL;
  CamelDataWrapper *dw = NULL;
  CamelMimeParser *parser = NULL;
 // CamelContentType *ct = NULL;
   int errwrap = 0;
  debug(__FILE__,__FUNCTION__,__LINE__,1);
 //if(IMToINet(pMapiMessage, szMessage) == hrSuccess){
 if(IMToINet(pMapiMessage, szMessage) != hrSuccess){
  debug(__FILE__,__FUNCTION__,__LINE__,1);
 printf(Message:\n  %s\n, szMessage);
 
 stream = camel_stream_mem_new();
 camel_stream_reset(stream);

no need to reset the stream here (a new stream's cursor always points to
the first byte)

 camel_stream_write(stream, szMessage, strlen(szMessage));

reset the stream *here*.

CamelStreams are just like normal POSIX file i/o... if you do:

fd = open (file, O_RDWR);
write (fd, data, len);

the cursor into the file is 'len' bytes into the file now and so if you
want to parse the resultant file from the beginning, you have to seek to
the beginning of the file, or any reads() will start at offset 'len'

 msg = camel_mime_message_new ();
 
   if(-1 == 
 camel_data_wrapper_construct_from_stream((CamelDataWrapper*) msg,stream)){
   printf(Hello World Data Wrapper);
 }else{
 //  stream = camel_stream_mem_new_with_buffer((const char*)szMessage, 
 strlen(szMessage));
 //  errwrap = camel_data_wrapper_construct_from_stream(dw,stream);
 
   printf (Error Wrap = \n);
 //  printf(mime_type = %s\n, camel_data_wrapper_get_mime_type(dw));
 }
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution 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] Fill a store with messages

2006-05-09 Thread Jeffrey Stedfast
Stores don't contain messages, only Folders do. See the
CamelFolderSummary class for that.

Jeff

On Tue, 2006-05-09 at 23:27 +0200, Smartuser wrote:
 Hello i'm kind of new in here and i've a question. About the stores. I've 
 mannaged to create a new provider in 
 evolution-data-server/camel/providers/testing 
 i also can get the thing to make me some folders. like inbox, outbox and 
 such. 
 The also includes the type and icon. but i don't know how to fill them with 
 messages. How do i fill the store with messages?
 
 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] Should I unref a CamelDataWrapper when I got it from camel_medium_get_content_object()?

2006-03-20 Thread Jeffrey Stedfast
I believe you are right, you should not be unreffing the
CamelDataWrapper returned by camel_medium_get_content_object()

Jeff

On Mon, 2006-03-20 at 13:05 +0100, Jules Colding wrote:
 Hi,
 
 I am seeing a lot of unref'ing of CamelDataWrapper object as returned
 from camel_medium_get_content_object() (mostly in the GW provider). 
 
 I do not see any ref'ing of the return value in
 camel_medium_get_content_object() which leads me to believe that any
 such unref'ing is wrong. 
 
 Am I correct?
 
 Thanks,
   jules
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
 
-- 
Jeffrey Stedfast
Evolution 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] g_mutex, e_mutex and pthread_mutex in camel?!

2006-03-13 Thread Jeffrey Stedfast
A cursory glance at EMutex suggests that GStaticRecMutex and EMutex
(recursive type) behave slightly differently which may cause problems...

Jeff

On Mon, 2006-03-13 at 14:57 +0100, Philip Van Hoof wrote:
 On Mon, 2006-03-13 at 12:54 +0100, Philip Van Hoof wrote:
 
  Is there a reason why g_mutex, e_mutex and pthread_mutex are used in a
  mixed may on libcamel?
 
 Note that the GStaticRecMutex can also be used as non-static:
 
 http://mail.gnome.org/archives/gtk-list/2002-January/msg00045.html
 
 It looks like recursive non-static mutexes is the only reason why EMutex
 is still in place.
 
 I'm willing to replace all those remaining mutexes to GStaticRecMutex if
 such a patch would eventually be applied. So are there any remaining
 issues with the GLib GThread mutex implementations?
 
 I'd like to do this to further decoupling camel from libedataserver.
 
 
  Anyway, I'm getting this segmentation fault on the
  CAMEL_DATA_WRAPPER_UNLOCK call in camel-data-wrapper.c 
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread -1226287424 (LWP 16199)]
  0x1098 in ?? ()
  (gdb) bt
  #0  0x1098 in ?? ()
  #1  0x0012 in ?? ()
  #2  0x0f40 in ?? ()
  #3  0xb7a3d653 in write_to_stream (data_wrapper=0x8067aa8,
  stream=0x8067c58) at camel-data-wrapper.c:149
  #4  0xb7a3d6d7 in camel_data_wrapper_write_to_stream
  (data_wrapper=0x8067aa8, stream=0x8067a38) at camel-data-wrapper.c:175
  
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED]  - www.novell.com

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Re: [evolution-patches] [Mailer] Possible fix for #333213

2006-03-06 Thread Jeffrey Stedfast
On Sat, 2006-03-04 at 19:03 +0800, simon.zheng wrote:
 Hi Jeffrey and all,
 
 On Fri, 2006-03-03 at 10:00 -0500, Jeffrey Stedfast wrote:
  The patch is bad because callers of e_iconv() expect errno to be set on
  -1 and your patch breaks that guarantee.
  
 
 Yeah, you're right.:) Instead of changing e_iconv(), can we do more
 checking when invoking e_iconv()?
 
  I would really appreciate seeing the section on iconv in the POSIX.1
  specification explaining what is meant and entailed by irreversable
  conversion and also whether this count is maintained thru multiple
  calls to iconv() or not[1].
 
 Post the lastest POSIX.1 specification.
 http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html
 
 non-identical conversation should be more exact term. It means a
 character in the input buffer that is valid, but for which an identical
 character does not exist in the target codeset. 
 
 And the return value is only related to the last call to iconv().
 
 So I think it's necessary to add more checking for return value, i.e. -1
 and positive value both mean some problems in conversation. Is that
 possible to change like below?
 
   if ((status == (size_t) -1) || status  (size_t) 0)
 return -1;

you don't need to cast (size_t) 0, but other than that - this type of
fix would be more agreeable with me :)

Jeff

 
 Thanks,
 -Simon
 
  
  that answered, yes, probably we should be checking that the count is not
   0 in the composer code and possibly other places in evolution as well.
  
  
  1. say, for example, I call iconv() and my outbuf isn't large enough -
  some conversion has still occured and it has possibly already made some
  irreversable conversions but since iconv() will return -1, how do I
  know? After making my nth call to iconv() finishing the conversion of
  all the data, will the return code of iconv() be the cumulative count of
  irreversable conversions? or only that of my last call to iconv()?
  
  On Fri, 2006-03-03 at 12:13 +0800, simon.zheng wrote:
   Hi,
   
   Bug 333213 – Can't specify the encoding as ISO-8859-15 in mail composer
   on Solaris.
   http://bugzilla.gnome.org/show_bug.cgi?id=333213
   
   Attached a patch for review. 
   
   Changing wrapper for iconv(). Translate non-zero value returned by
   iconv() to -1.
   
   Thanks,
   -Simon
   ___
   Evolution-patches mailing list
   [EMAIL PROTECTED]
   http://mail.gnome.org/mailman/listinfo/evolution-patches
 
-- 
Jeffrey Stedfast
Evolution 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] ... and how camel should be

2006-02-14 Thread Jeffrey Stedfast
On Tue, 2006-02-14 at 19:40 +0100, Philip Van Hoof wrote:
 On Tue, 2006-02-14 at 13:02 -0500, Lee Revell wrote:
  On Tue, 2006-02-14 at 18:57 +0100, Philip Van Hoof wrote:
  
  I really don't think the message IDs are the main source of bloat in
  Evo.
 
 I measured it ;-)
 
 10.000 E-mails used +-8MB of memory.
 
 This is how I quickly measured it.
 
 gint s=0;
 
 static void measure (gpointer data, gpointer user_data)
 {
   s += strlen ((const char*)data);
 }
 
 GPtrArray *uids = camel_folder_get_uids (folder);
 g_ptr_array_foreach (uids, measure, NULL);
 g_print (%d\n, s);
 
 Luckily the format of those message ids is a small string version of the
 follow-up number. So 0,1, 2, .. . So it's a lot small
 strings. Which is of course better then a lot message-id headers
 
 But if it's a follow-up, I wonder why not simply return the total amount
 of messages in a folder, and let the developer use a simple loop like:
 
 for (i=0; ithat_length; i++)
 {
   msg = camel_ folder_get_message_info (folder, i);
 }

we don't do that because the uids are not necessarily contiguous. You
might have 1, 3, 4, 5, 7, 109, 110

Refer to the IMAP specification for further info on how UIDs work. Hint:
They are NOT message-ids nor are the sequence-ids.

-- 
Jeffrey Stedfast
Evolution 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] ... and how camel should be

2006-02-14 Thread Jeffrey Stedfast
Have fun implementing this on your own. I guess you don't need my help.

On Tue, 2006-02-14 at 19:03 +0100, Philip Van Hoof wrote:
 On Tue, 2006-02-14 at 11:06 -0500, Jeffrey Stedfast wrote:
 
  Even for single-user, disk-summary-branch was slower than the current
  in-memory implementation.
 
 Try this one:
 
 Even for a single-user, running the entire system from disk was slower
 than the current put-everything-in-a-ram-disk implementation.
 
 Duh.
 
 
-- 
Jeffrey Stedfast
Evolution 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] ... and how camel should be

2006-02-14 Thread Jeffrey Stedfast
This example is total bollocks, you don't even understand how a uid is
used or what it even is. I've explained it to you a number of times now
and you still don't get it. UIDs are not guaranteed to be contiguous.

Jeff

On Tue, 2006-02-14 at 21:30 +0100, Philip Van Hoof wrote:
 On Tue, 2006-02-14 at 21:15 +0100, Philip Van Hoof wrote:
  On Tue, 2006-02-14 at 14:03 -0500, Lee Revell wrote:
 
   Do you think that's a problem?
  
  For evolution, it might be a lesser problem than for camel. I'd like to
  start using camel on mobile devices.
 
 Let me illustrate this specific case . . .
 
 Imagine .. a mobile device as 50 MB ram (that's a lot for some devices).
 
 Now your library has a function like this:
 
 GPtrArray *give_ids (void);
 
 It will return pointers to 7MB  of strings like this:
 
 0, 1, 2, ... 1
 
 Wouldn't it be better if I could simply do this then?
 
 gint give_length (void);
 
 for (int a=0; a  give_length(); a++)
 {
   /* or whatever fast implementation */
   gchar *id = g_strdup_printf (%d, a);
 
   /* my stuff */
 
   g_free (id); 
 }
 
 No? Because, that would safe me a 7 MB allocation on a device that has
 50 MB of ram it REALLY wants to use for other purposes (believe me, if
 on such a device you don't have to waste it like that, you DON'T waste
 it like that).
 
 Now .. I payed money for the memory in my desktop. Imagine EVERY
 application wasting 7MB of memory. At this moment I have 24 applications
 running. If they would all start doing things like that only ONCE, it
 would waste +- 168 MB of ram. That's +- 15 euros.
 
 Now lets take a look at the One Laptop Per Child project. 
 
 We can save some euros by fixing this flaw. We can make it possible to
 give poor children a very good E-mail client that uses camel.
 
 Is it still not worth fixing?
 
 
 I strongly disagree.
 
 
-- 
Jeffrey Stedfast
Evolution 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] CamelStore.get_folder() with no folder name

2006-01-04 Thread Jeffrey Stedfast
looks like a bug... or maybe it's the same as requesting the default
folder. I forget :(

Jeff

On Wed, 2006-01-04 at 15:08 +0100, Jules Colding wrote:
 Hi,
 
 I am seeing that get_folder() is being invoked with the empty string as
 folder name as in:
 
 my_provider_store-get_folder(some_store, , 0, ex);
 
 What am I expected to return here?
 
 Thanks,
   jules
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
 
-- 
Jeffrey Stedfast
Evolution 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] Logic flaw in header_decode_lwsp()

2005-12-02 Thread Jeffrey Stedfast
On Fri, 2005-12-02 at 15:19 +0100, Jules Colding wrote:
 Hi,
 
 The following while statement does not make sense:
 
 # snip ###
 static void
 header_decode_lwsp(const char **in)
 {
   const char *inptr = *in;
   char c;
 
   d2(printf(is ws: '%s'\n, *in));
 
   while (camel_mime_is_lwsp(*inptr) || (*inptr =='('  *inptr != '\0')) {
 .
 .
 .
 
 # snip ###
 
 If *inptr is equal to '(' then it is per definition not equal to '\0'. 
 
 OK, does not makes sense might to harsh, but it definitely does not
 seem to done this way on purpose. 

indeed, and while I was fixing that logic problem I also removed the
'\0' check since it isn't needed in any way (if it is lwsp or '(' then
it can't be \0)



 
 
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED]  - www.novell.com
Index: ChangeLog
===
RCS file: /cvs/gnome/evolution-data-server/camel/ChangeLog,v
retrieving revision 1.2497
diff -u -r1.2497 ChangeLog
--- ChangeLog	2 Dec 2005 08:54:44 -	1.2497
+++ ChangeLog	2 Dec 2005 19:13:50 -
@@ -1,3 +1,11 @@
+2005-12-02  Jeffrey Stedfast  [EMAIL PROTECTED]
+
+	* camel-mime-utils.c (header_decode_lwsp): fixed loop bounds
+	checking - we don't need to check for != '\0' if we are checking
+	that it is specifically lwsp || '('.
+	(camel_header_unfold): Fixed to only check the subset of LWSP that
+	is allowable to make the code more clear.
+
 2005-12-02  Shi Pu [EMAIL PROTECTED]
 
 	** See bug #321139
@@ -128,7 +136,7 @@
 
 	* camel-vtrash-folder.c: (vtrash_remove_folder):
 	check if mi-real exists, continue otherwise. 
-	
+
 2005-10-11 Vivek Jain [EMAIL PROTECTED]
 
 	** See bug #318508
Index: camel-mime-utils.c
===
RCS file: /cvs/gnome/evolution-data-server/camel/camel-mime-utils.c,v
retrieving revision 1.234
diff -u -r1.234 camel-mime-utils.c
--- camel-mime-utils.c	15 Sep 2005 17:35:45 -	1.234
+++ camel-mime-utils.c	2 Dec 2005 19:13:51 -
@@ -970,8 +970,8 @@
 
 	d2(printf(is ws: '%s'\n, *in));
 
-	while (camel_mime_is_lwsp(*inptr) || (*inptr =='('  *inptr != '\0')) {
-		while (camel_mime_is_lwsp(*inptr)  inptr != '\0') {
+	while (camel_mime_is_lwsp(*inptr) || *inptr =='(') {
+		while (camel_mime_is_lwsp(*inptr)) {
 			d2(printf((%c), *inptr));
 			inptr++;
 		}
@@ -4479,10 +4479,10 @@
 	o = out;
 	while ((c = *inptr++)) {
 		if (c == '\n') {
-			if (camel_mime_is_lwsp(*inptr)) {
+			if (*inptr == ' ' || *inptr == '\t') {
 do {
 	inptr++;
-} while (camel_mime_is_lwsp(*inptr));
+} while (*inptr == ' ' || *inptr == '\t');
 *o++ = ' ';
 			} else {
 *o++ = c;
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] camel_header_unfold()

2005-11-29 Thread Jeffrey Stedfast
On Tue, 2005-11-29 at 09:55 +0100, Jules Colding wrote:
 On Mon, 2005-11-28 at 12:12 -0500, Jeffrey Stedfast wrote:
  I see what you are thinking, but by the time this code is run on any
  input, the \r has already been stripped and you cannot, by definition,
  have \n\n in a header (it terminates the header block so we don't have
  to worry about that).
  
  I suppose the following modification could be made to be more clear:
  
  char *
  camel_header_unfold(const char *in)
  {
  char *out = g_malloc(strlen(in)+1);
  const char *inptr = in;
  char c, *o = out;
  
  o = out;
  while ((c = *inptr++)) {
  if (c == '\n') {
  if (*inptr == ' ' || *inptr == '\t') {
  do {
  inptr++;
  } while (*inptr == ' ' || *inptr == '\t');
  *o++ = ' ';
 
 Might be nitpicking, but RFC 2822 says:
 
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
unfolding. Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP.  Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.
 
 So it appears to me that too much is being removed above. Shouldn't the
 unfolding operation simply remove the CRLF and nothing else?

if you wanted to get nitty gritty to the finer details of the spec,
sure, but in reality it's much nicer to get rid of the extra whitespace
many clients stick in there when folding.

Often, mailers will folder part1 part2 into part1\n\tpart2 or part1
\n\t part2 or sometimes even part1\npart2

Anyways, if we wanted to remove the unfolding niceness, we'd simply
remove that inner loop and it'd be fixed.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED]  - www.novell.com

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


  1   2   >