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
