Re: Camel in evolution-data-server, a different proposal

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.