Re: [Evolution] The hump on Evolution's back ...

   to do this).  Remove the data wrapper repository - it
   doesn't really serve any real use (it can be replaced by
   a 3 line switch statement ...).

I almost removed it a week ago, and then realized that it allows the
application (or a provider) to extend the core library's
functionality. I don't know how interesting this possibility is.

Well, it can be added back if really necessary.  But the
message structure is pretty limited in mime, and the
mime parser will force a certain structure (actually
it needs to know about all the structure types, so even
more the data repository cannot be used).

A provider can override the create_from_* which can provide
its own objects to the structure (the imap provider may
have to do this), and the data repositroy cannot be used
for that anyway.

 - Add the rest of the rfc822 headers to camel-mime-message (it
   currently misses out a lot).

Yeah, but do we care about any of those headers enough that having to
go through the camel-medium interfaces would matter?

Most of them will probably be worth it, just for completeness,
and they will be very small amounts of code.

 - Better selection of charsets for rfc2047 encoding (it
   only does us-ascii, iso-8859-1 and utf-8 at the moment).

This should probably go into libunicode. Actually, I wonder if Owen
has already written something to do this for Pango (for picking a font
to use to display a UTF-8 string)

Yes, i'd agree.  Anything more than the trivial implementation
that is there is going to require the same data unicode_iconv
already has access to (and it is kinda bulky stuff).  Of course
the browser doesn't display unicode yet either.

On a side note libunicode can never be compliant with the unicode
standard (for those that dont know) as it uses 32 bit unicode_char_t,
rather than having a 16 bit interface (see chapter 3 of The Unicode
Standard, Version 3).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]