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

[NotZed <notzed helixcode com>]

> >    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).

 Michael