On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:
> On Wed, 2006-07-12 at 17:00 +0100, Ross Burton wrote:
> > On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
> > So you are proposing the following library packages:
> >
> > libedataserver
> > libedataserverui
> > libebook
> > libedata-book
> > libecal
> > libedata-cal
> > libgroupwise
>
> > And then binary packages for the Groupwise helpers, the Exchange
> > helpers, and the server binaries themselves.
>
> Yeah. Sounds perfect. Looks very clean.
... and fragments the platform.
> At this moment, all those fall under the name of "evolution comma data
> comma server". Some of these libraries (like Camel) don't necessarily
> have "anything" to do with the Evolution data that is being managed by
> the data server of Evolution.
They have a lot to do with it. iMip for calendaring for example (really
you want the imip direct mail fall back to happen in e-d-s, not the
client).
There was also an idea to tie in a unified account settings dialog so
that exchange/groupwise/jecs could be configured in a unified manner.
> The E-mails and, folder-summaries, state data and summaries of Camel are
> *not at all* being managed by Evolutions data server. It's simply
> totally unrelated to the Evolutions data server. It looks like even some
> Novell employees don't know that, probably cause it's being marketed as
> "one" package.
There were plans to look at this. In fact I discussed such a scenario
with Jeff last week. Speed was always a major concern however, but
something like the disk summary branch might alleviate this.
> The ideal situation would be that most of these components would be
> reusable by application developers that don't have to use the Evolution
> data server at all.
>
> Why glue it?
I think you're only real example is camel, which shares code with the other
pieces anyhow.
-JP
--
JP Rosevear <[EMAIL PROTECTED]>
Novell, Inc.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
