Re: [Evolution-hackers] Camel plans and possibilities
- From: Not Zed <notzed ximian com>
- To: Ettore Perazzoli <ettore ximian com>
- Cc: Evolution Hackers Mailing List <evolution-hackers ximian com>
- Subject: Re: [Evolution-hackers] Camel plans and possibilities
- Date: 30 Jun 2003 11:36:09 +0930
On Fri, 2003-06-27 at 05:39, Ettore Perazzoli wrote:
> Hi Michael,
>
> thanks for putting this into writing.
>
> > - should remove dependent headers from header files, force client code
> > to include appropriate header dependencies, a-la libc.
>
> Why? What problems does the current setup cause?
Well, having to build the stuff N times a year, where N is much larger
than 365, it would improve build performance markedly.
> None of the other GNOME libraries does this, and it's much nicer to use
> a library when you don't have to include multiple headers just to get
> one class/functionality.
Its basically a busted mode of operation. Especially when some of the
header files can include so much, and include the same stuff over and
over again. libc doesn't do this anywhere near as much.
> > - what to do about e-util - we only use a few non-gui related files
> > from e-util,
> > could either copy, or move them to camel/e-util and rename it.
>
> Yeah I think most (all?) of the stuff that Camel needs from e-util is
> only needed by Camel itself or the mailer.
Most of it would be useful outside of it though, particularly if things
became more threaded, which they should, but they probably wont.
> > nntp
> > - unmaintained
>
> We should keep a list of things like this one that could have appeal for
> other contributors. Although I don't see many people getting excited
> about NNTP these days...
Yeah its a funny one, you get a lot of people whining about it, but
nobody gives enough of a shit to even ask about doing work on it. There
isn't even much work required.
> > camel.h
> > - imho, remove this, or at least, change it not to inlude all of camel
>
> I don't think it should be removed. It's nice to just do #include
> <camel.h> if you just want all the functionality and do not care about
> inclusion speed.
> (I don't want to sound pedantic, but if we are going to export more APIs
> from Evolution we should make them consistent, so we should agree on
> these details.)
What other api's are exported from evolution?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]