Re: [Evolution-hackers] Camel plans and possibilities



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

As long as headers include only the dependencies and the user of the
headers includes only the headers it needs, I doubt it is a performance
problem.

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

Yes but libc is also annoying as hell to use.  ;-)

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

Maybe we should split it up into a library of utility functions that we
also export?  I don't know exactly what functions you are thinking
about, so I am not sure whether it would make sense...

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

We need to lower the barrier for people who want to hack this kind of
stuff.  The whole thing looks very intimidating to a hacker who hasn't
seen it before...  Hopefully exporting and documenting the APIs is going
to help that.

> > (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?

Currently none, but as we discussed before we need to stabilize,
document and export the addressbook, mailer and shell APIs as well as
the Camel ones.  And these APIs should be consistent with the basic
conventions of other GNOME libraries, so that they are easy for GNOME
hackers to use.

-- Ettore



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