Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-22 Thread Philip Van Hoof
On Sat, 2006-07-22 at 00:00 +0300, Tor Lillqvist wrote:
 on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof:

  It simply looks like Evolution developers didn't know where to stack all
  these Evolution libraries. And thought .. oh, we already had this
  Evolution data server thing .. lets simply put it there.
 
 During the 2.6 development phase and the Win32 porting (spring 2005,
 roughly), many functions were identified that were duplicated (!) in the
 evolution-data-server, evolution and evolution-exchange modules
 (module in the CVS sense). They were kept in/moved to libedataserver,
 simply because that seemed to be the best place as everything else
 linked to it already anyway, and I didn't want to add yet another
 library.

Yep.

And the point that I tried to make was that copypasting this into a
larger library that doesn't have a lot to do with the functionality
being copypasted, makes the gateway to using this functionality (the
library itself) needlessly more difficult (larget) for applications that
use the functionality out of the scope with Evolution.

Look at camel-builder-lite test. I identified six files that don't
cross-use any of the other files in the libedataserver library. You
don't have to change a single line in them. Just isolate them in the
Makefile.am and recompile.

https://svn.tinymail.org/svn/camel-lite-builder/trunk

This, in my opinion, can alienate the shareable functionality from
applications that could otherwise have used it in a shared way with
Evolution.

In the long term it could maybe alienate very good and nice shareable
Evolution code from the community as well. That might maybe, who knows,
result in fewer people using this awesome code. Maybe, you never know,
fewer people caring about it. Which might, but I'm not sure, get us
fewer people contributing enhancements back to Evolution.

I have customers and end-users that are building mobile devices that
will *not* come with contactbook nor addressbook functionality. Why
would I want to ship a libedataserver that contains 1.5 megs of
functionality that my Camel isn't using? The answer is rather simple: I
don't want that: so, that's why .. camel-lite-builder, another hack.


.
.
.


(A little bit off topic and not technical)
The vertical, mobile and embedded market. The different story:

People who say that it's impossible to have a mobile user that doesn't
want contactbook nor addressbook functionality, might not really
understand the embedded and mobile world. Especially not the embedded
world.

It doesn't really work like that at all. Vendors of such devices want to
make choices. They will define the price, in yes a pure sales way,
based on this functionality. 

That's because people want choice. This is why WinCE is not as
successful on devices as Windows XP on the desktop: people want their
device to be their personal device. It must expose the functionality
that they personally desire. Whether that is an injected feeling by a
sales guy or not, doesn't really matter *at all*.

I'm soon going to have customers that will ask me: I'm this software
builder for a customer that wants a vertical application that integrates
showing E-mails in a very specific way that are stored on their Exchange
server. I only want the application to show E-mails that are tagged in a
specific way.

I don't see how this customer already needs contactbook and addressbook
functionality.

I would certainly understand that this isn't what Evolution wants. But
people here *really* *ask* me to work upstream for the enhancements that
I do to Camel for tinymail. Or ... don't they?

Maybe you know these fancy cafes where you can get yourself a cocktail
and where the waitress notes down your order on a PocketPC? It gets
transferred (using a webservice over wifi) straight to the bar. When
miss waitress has wrote down all the orders ... the drinks are already
ready. We have those in Belgium.

How does that device need contactbook or addressbook functionality? If
it needs 2 MB more memory for functionality it will not use, the price
of the hardware might go up drastically. Some of these businesses order
1,000ths of such devices.

But functionality to show messages that the bar-guy sends to the girl: I
can imagine *that* being important for their business. It doesn't have
to be important. Contactbook and addressbook functionality might also be
important. My point is: choice. 

Welcome to the vertical market.


 There used to be, even earlier, a module called gal (GNOME Application
 Library I think) containing a library libgal, which got scrapped
 (presumably because nothing except Evolution (and e-d-s) used it despite
 its name) from which some of these functions had been copy-pasted. In
 retrospect, perhaps scrapping libgal wasn't a good idea after all, maybe
 it should just have been renamed, to libevolution-and-friends or
 whatever?

 Somebody please correct me if my memory serves me wrong...



-- 
Philip Van Hoof, software developer at x-tend 

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-22 Thread Ross Burton
On Sat, 2006-07-22 at 12:04 +0200, Philip Van Hoof wrote:
 I have customers and end-users that are building mobile devices that
 will *not* come with contactbook nor addressbook functionality. Why
 would I want to ship a libedataserver that contains 1.5 megs of
 functionality that my Camel isn't using? The answer is rather simple: I
 don't want that: so, that's why .. camel-lite-builder, another hack.

As I pointed out before the 1.5M impact is due to statically linking
BDB.  If your target system has BDB, and frankly a huge number of
devices have it, then dynamically link and libedataserver is nearer
100K.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-21 Thread Tor Lillqvist
on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof:
 It simply looks like Evolution developers didn't know where to stack all
 these Evolution libraries. And thought .. oh, we already had this
 Evolution data server thing .. lets simply put it there.

During the 2.6 development phase and the Win32 porting (spring 2005,
roughly), many functions were identified that were duplicated (!) in the
evolution-data-server, evolution and evolution-exchange modules
(module in the CVS sense). They were kept in/moved to libedataserver,
simply because that seemed to be the best place as everything else
linked to it already anyway, and I didn't want to add yet another
library.

There used to be, even earlier, a module called gal (GNOME Application
Library I think) containing a library libgal, which got scrapped
(presumably because nothing except Evolution (and e-d-s) used it despite
its name) from which some of these functions had been copy-pasted. In
retrospect, perhaps scrapping libgal wasn't a good idea after all, maybe
it should just have been renamed, to libevolution-and-friends or
whatever?

Somebody please correct me if my memory serves me wrong...

--tml



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-20 Thread Philip Van Hoof
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote:
 On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:
  I wasn't (am no longer) proposing to move camel/ out of e-d-s. I was
  proposing to put a configure.ac file in its directory. Moving Camel out
  of evolution-data-server/ is not the scope nor point of this thread.
 
 For what purpose?  Camel depends on libedataserver.

Small correction:

It depends on e-trie.c, e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c,
e-time-utils.c, e-data-server-util.c, md5-utils.c which is compiled in
libedataserver. These files themselves don't depend on anything other in
libedataserver.

I also have a clean configure.ac ready that will only build a Camel, and
a set of Makefile.am's that will build a static libedataserver using
only the listed files above.

Stripped a fully functional Camel x86 build uses 315K for libcamel, 339K
for libcamel-provider and 868K for camel-providers/*


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-20 Thread Philip Van Hoof
On Thu, 2006-07-20 at 10:05 +0200, Philip Van Hoof wrote:
 On Mon, 2006-07-17 at 15:35 -0400, JP Rosevear wrote:
 
  I think you're only real example is camel, which shares code with the other 
  pieces anyhow.
 
 Knowing is a good idea.

Hrmm. After re-reading my own stuff, I apologise for the tone. I'm not
afraid of admitting when I make a mistake.

I'll rewrite:

I think it's interesting to know on which code-pieces Camel depends.
This will make future decisions and discussions about it more easy.

For that reason I decided to investigate it a little it. It turns out
only the following files are being used by Camel: e-trie.c, e-iconv.c,
e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c, e-data-server-util.c,
md5-utils.c


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-17 Thread JP Rosevear
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


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Ross Burton
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:
  
   It's cleaner in my opinion :-), and I can more easily create a tar.gz
   release.
  
  Cleaner for what reasons?
 
 Because it will be more easy to pick which libraries you will use (in
 your application that integrates with the e-d-s framework).

This is only for the case of the developer who is both writing an
application and developing the underlying libraries, and is also only
using a subset of the libraries, right?  That is pretty much you.

The Evolution hackers are using the entirety of EDS obviously, Chris
Lord (Dates and Contacts developer) isn't developing the libraries (just
using the packages I produce for Maemo), and although the 770 uses only
the addressbook we disable Camel and Calendar at configure time.

There is no reason why you can't just take the eds tarball, build
packages, and use just libcamel.deb on Maemo, or any other platform.

X has taken the modular route, but in that case the composite tarball
was *huge*, and many parts of it hadn't changed for years.  There
splitting it up into separate packages made absolute sense (although it
did cause huge amounts of pain on the packages, LFS users still moan
about the modular packaging on xorg-list).  I don't see how splitting
EDS into ~10 library packages would help anyone apart from you, as you
don't want to have a large source tarball for a camel package.

[snip]
 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.

hyphen, not comma.

EDS is a far better place for Camel than in Evolution itself, which is
where it is.  EDS is a library for storing and accessing PIM data, and
email is part of this.

 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.

Calendar data isn't being stored by the addressbook server either.  That
isn't a great argument.

[snip rant]

 Conclusion .. all this coupling with Evolution and Evolution Data Server
 is making it harder for application developers to actually *use* the
 provided functionality.

You are talking entirely from a packaging point of view.  Yes, it would
be nice to have an option to at configure time disable the address book,
or the calendar (I have the latter in eds-dbus).  Being able to enable
and disable backends selectively would also be nice.  I'm sure patches
for this would be considered.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Harish Krishnaswamy
On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:

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

Which Novell employees ? 

 It simply looks like Evolution developers didn't know where to stack all
 these Evolution libraries. And thought .. oh, we already had this
 Evolution data server thing .. lets simply put it there.

 It's not good a solution, imo. A library is a library. We have package
 systems (like yum and apt) to solve the dependency problem for users.

Evolution-Data-Server handles PIM data - (mail / calendaring / contacts
information, journals) packaging them together *does* make lot of sense.

I do not think you are suggesting that every library should be packaged
separately, are you ?


snip
 Conclusion .. all this coupling with Evolution and Evolution Data Server
 is making it harder for application developers to actually *use* the
 provided functionality.

The current packaging *is* good for users and packaging systems.
As for the application developers, you are certainly not the first one
to tread this path.

Ask Gaim. Clock applet. Contact applet. Open Office. Planner. Beagle.



Philip - Nobody is any better with these long winding arguments back and
forth. Can we get to the business at hand ?

Let us spend our energies together on the camel-mmap patch instead.


--Harish
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Philip Van Hoof
On Thu, 2006-07-13 at 10:24 +0100, Ross Burton wrote:
 On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:

 This is only for the case of the developer who is both writing an
 application and developing the underlying libraries, and is also only
 using a subset of the libraries, right?  That is pretty much you.

Maybe I'm the only one. Maybe because it's not easy to do so?

 The Evolution hackers are using the entirety of EDS obviously, Chris
 Lord (Dates and Contacts developer) isn't developing the libraries (just
 using the packages I produce for Maemo), and although the 770 uses only
 the addressbook we disable Camel and Calendar at configure time.

 There is no reason why you can't just take the eds tarball, build
 packages, and use just libcamel.deb on Maemo, or any other platform.

But it's more work (and less clean) to put AM_CONDITIONALS in
Makefile.am files and funny if-then-else and pkg-config magic in
configure.in, than it is to simply make a new configure.ac file in
evolution-data-server/camel/ and cleanup the configure.in of eds itself.


 X has taken the modular route, but in that case the composite tarball
 was *huge*, and many parts of it hadn't changed for years.  There
 splitting it up into separate packages made absolute sense (although it
 did cause huge amounts of pain on the packages, LFS users still moan
 about the modular packaging on xorg-list).  I don't see how splitting
 EDS into ~10 library packages would help anyone apart from you, as you
 don't want to have a large source tarball for a camel package.

Adding a configure.ac to evolution-data-server/camel doesn't change
anything to the tar.gz being produced for desktops (except a few more
bytes in size, because we added a file).

 [snip]
  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.
 
 hyphen, not comma.
 
 EDS is a far better place for Camel than in Evolution itself, which is
 where it is.  EDS is a library for storing and accessing PIM data, and
 email is part of this.

I wasn't (am no longer) proposing to move camel/ out of e-d-s. I was
proposing to put a configure.ac file in its directory. Moving Camel out
of evolution-data-server/ is not the scope nor point of this thread.

 Calendar data isn't being stored by the addressbook server either.  That
 isn't a great argument.

And I question ... do all applications that want to use calendaring (and
only calendaring) have to depend on most of the Evolution components?

Right now, if you translate that to Camel and E-mailing, it depends on
which distribution you have. On most Redhat based ones: yes. On Debian
based ones: no. Is there clarity? no. Is it making it more easy to
develop a pure E-mail application and to document which dependencies
you have (maybe even letting packagers share the same dependencies): no.

The list of reasons (all valid ones, it's not because *you* mark them as
rant that it also *is* rant) goes on and on and on.

  Conclusion .. all this coupling with Evolution and Evolution Data Server
  is making it harder for application developers to actually *use* the
  provided functionality.
 
 You are talking entirely from a packaging point of view.  Yes, it would
 be nice to have an option to at configure time disable the address book,
 or the calendar (I have the latter in eds-dbus).  Being able to enable
 and disable backends selectively would also be nice.  I'm sure patches
 for this would be considered.

Like adding a configure.ac to eds/camel ? ;-)


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Philip Van Hoof
On Thu, 2006-07-13 at 15:58 +0530, Harish Krishnaswamy wrote:

 Evolution-Data-Server handles PIM data - (mail / calendaring / contacts
 information, journals) packaging them together *does* make lot of sense.

 I do not think you are suggesting that every library should be packaged
 separately, are you ?

Well ;-)  not should. But it would be nice yes. All of the libraries
that require the server to run, however, do perhaps indeed belong to the
same package / tarball.

 Philip - Nobody is any better with these long winding arguments back and
 forth. Can we get to the business at hand ?
 
 Let us spend our energies together on the camel-mmap patch instead.

I agree. Nevertheless, it's my opinion that evolution-data-server can be
better organised. It's, however, not blocking me. It's just annoyances.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Ross Burton
On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:
 I wasn't (am no longer) proposing to move camel/ out of e-d-s. I was
 proposing to put a configure.ac file in its directory. Moving Camel out
 of evolution-data-server/ is not the scope nor point of this thread.

For what purpose?  Camel depends on libedataserver.

  Calendar data isn't being stored by the addressbook server either.  That
  isn't a great argument.
 
 And I question ... do all applications that want to use calendaring (and
 only calendaring) have to depend on most of the Evolution components?

 Right now, if you translate that to Camel and E-mailing, it depends on
 which distribution you have. On most Redhat based ones: yes. On Debian
 based ones: no. Is there clarity? no. Is it making it more easy to
 develop a pure E-mail application and to document which dependencies
 you have (maybe even letting packagers share the same dependencies): no.
 
 The list of reasons (all valid ones, it's not because *you* mark them as
 rant that it also *is* rant) goes on and on and on.

So you've found a problem with the Red Hat packaging, in that it treats
all of EDS a single library.  File a bug with Red Hat, and notice that
Debian, Maemo, and OpenEmbedded (at least) already have split EDS
packages.

In the scheme of things this is a very minor issue which effects very
few people.  I'd prefer to see effort spent on fixing bugs and memory
leaks.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Philip Van Hoof
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote:
 On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:

  I wasn't (am no longer) proposing to move camel/ out of e-d-s. I was
  proposing to put a configure.ac file in its directory. Moving Camel out
  of evolution-data-server/ is not the scope nor point of this thread.
 
 For what purpose?  Camel depends on libedataserver.

Being a developer, I can probably fix that chicken and egg problem in a
few hacking evenings.

 So you've found a problem with the Red Hat packaging, in that it treats
 all of EDS a single library.  File a bug with Red Hat, and notice that
 Debian, Maemo, and OpenEmbedded (at least) already have split EDS
 packages.

I very much applaud what OpenEmbedded, Maemo, OpenedHand and Debian did
in terms of packaging. It's indeed the right way.

 In the scheme of things this is a very minor issue which effects very
 few people.  I'd prefer to see effort spent on fixing bugs and memory
 leaks.

I agree it's a minor issue. But things can happen in parallel. This is
why people developed round robin algorithms in schedulers :). Else the
minor ones or very-low-priority ones never get any attention from the
processing unit (because the large ones eat up exactly 100% of the
processing units time).

However, I do agree that we are putting to much of a discussion/fight on
it. It should probably simply be a patch and a get-it-over-with commit.


ps. Is there a beach at the Boston Summit? Maybe we can do a beach-fight
about it? :-) (ps. I'm not yet sure if I will attent the summit).

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Frederic Crozat
Le jeudi 13 juillet 2006 à 11:35 +0100, Ross Burton a écrit :
 On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:

   Calendar data isn't being stored by the addressbook server either.  That
   isn't a great argument.
  
  And I question ... do all applications that want to use calendaring (and
  only calendaring) have to depend on most of the Evolution components?
 
  Right now, if you translate that to Camel and E-mailing, it depends on
  which distribution you have. On most Redhat based ones: yes. On Debian
  based ones: no. Is there clarity? no. Is it making it more easy to
  develop a pure E-mail application and to document which dependencies
  you have (maybe even letting packagers share the same dependencies): no.
  
  The list of reasons (all valid ones, it's not because *you* mark them as
  rant that it also *is* rant) goes on and on and on.
 
 So you've found a problem with the Red Hat packaging, in that it treats
 all of EDS a single library.  File a bug with Red Hat, and notice that
 Debian, Maemo, and OpenEmbedded (at least) already have split EDS
 packages.

Mandriva too ;)

-- 
Frederic Crozat [EMAIL PROTECTED]
Mandriva

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-12 Thread Ross Burton
On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote:
 Okay, forking Camel is not what I want. Nobody wants that. It's not a
 good idea.
 
 However, it would be more easy (for me) if Camel would have its own
 configure.ac file. That way would it be more easy to do a 'make dist' of
 just Camel, I think.
 
 The evolution-data-server configure.in could very easily forward the
 configure stage of Camel using AC_CONFIG_SUBDIRS()
 
 I think it's even possible to pass variables from the first configure.in
 to the next configure.ac. And if not, I guess we can simply write-out a
 m4 file and m4_include() that one in the second configure.ac. For
 example in case you want to pass version information from a to b.

What advantages does being able to dist camel on its own have, over
simply packaging it in a separate package like OpenEmbedded and Debian
do:

$ apt-cache show libcamel1.2-8
Package: libcamel1.2-8
Maintainer: Takuo KITAME [EMAIL PROTECTED]
Architecture: i386
Source: evolution-data-server
Version: 1.6.1-0ubuntu5
Depends: libc6 (= 2.3.4-1), libcomerr2 (= 1.33-3), libedataserver1.2-7 (= 
1.6.1), libegroupwise1.2-9 (= 1.6.1), libglib2.0-0 (= 2.10.0), libgnutls12 
(= 1.2.5), libkrb53 (= 1.4.2), libsoup2.2-8 (= 2.2.92), libxml2 (= 2.6.24), 
zlib1g (= 1:1.2.1), libnss3
Description: Generic messaging library for evolution data servers
 The data server, called Evolution Data Server is responsible for managing
 calendar and addressbook information.

Before you can dist it as a separate package you'll need to remove the
use of libedataserver.  That might not be possible or realistic, so I'd
attempt that first.

If you find large bits of code that are only used in camel and are
currently in libedataserver, I'd propose moving them into camel:
libedataserver could do with slimming down.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-12 Thread Philip Van Hoof
On Wed, 2006-07-12 at 16:30 +0100, Ross Burton wrote:
 On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote:

 What advantages does being able to dist camel on its own have, over
 simply packaging it in a separate package like OpenEmbedded and Debian
 do:

It's cleaner in my opinion :-), and I can more easily create a tar.gz
release.

 Before you can dist it as a separate package you'll need to remove the
 use of libedataserver.  That might not be possible or realistic, so I'd
 attempt that first.

Or do all the libraries in evolution-data-server with their own
configure.ac?

 If you find large bits of code that are only used in camel and are
 currently in libedataserver, I'd propose moving them into camel:
 libedataserver could do with slimming down.

For example EMsgPort, is that used by something else but Camel?

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-12 Thread Ross Burton
On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
  What advantages does being able to dist camel on its own have, over
  simply packaging it in a separate package like OpenEmbedded and Debian
  do:
 
 It's cleaner in my opinion :-), and I can more easily create a tar.gz
 release.

Cleaner for what reasons?

  Before you can dist it as a separate package you'll need to remove the
  use of libedataserver.  That might not be possible or realistic, so I'd
  attempt that first.
 
 Or do all the libraries in evolution-data-server with their own
 configure.ac?

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.

I'm also not sure where the backends would go in this scheme.

No, I don't think that is a good idea either.

  If you find large bits of code that are only used in camel and are
  currently in libedataserver, I'd propose moving them into camel:
  libedataserver could do with slimming down.
 
 For example EMsgPort, is that used by something else but Camel?

By the magic of grep, libedataserverui/e-passwords.c uses e-msgport.c.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-12 Thread Philip Van Hoof
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:
 
  It's cleaner in my opinion :-), and I can more easily create a tar.gz
  release.
 
 Cleaner for what reasons?

Because it will be more easy to pick which libraries you will use (in
your application that integrates with the e-d-s framework).

   Before you can dist it as a separate package you'll need to remove the
   use of libedataserver.  That might not be possible or realistic, so I'd
   attempt that first.
  
  Or do all the libraries in evolution-data-server with their own
  configure.ac?
 
 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.

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.

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.

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?

It simply looks like Evolution developers didn't know where to stack all
these Evolution libraries. And thought .. oh, we already had this
Evolution data server thing .. lets simply put it there.

It's not good a solution, imo. A library is a library. We have package
systems (like yum and apt) to solve the dependency problem for users.
And you see that distributions like Debian have to re-split it up
anyway.

 I'm also not sure where the backends would go in this scheme.

Perfect example! ;-)

It's actually for the backends why I would like this. At this moment
it's not very easy to build a Camel provider for a mobile device for
Exchange. Mainly because in order to compile it, I have to get a lot
non-Camel related things compiling as well.

Or I basically have to insanely patch the Makefile.am's and configure.ac
file of evolution-exchange just to build its Camel provider. Why is
that? In the end, I'm really only interested in the Camel provider!

I don't want to implement some Evolution widget or pane for Exchange,
nor do I want to implement calendaring support or whatever, if I just
want to create an E-mail client for a mobile device that can show the
user his Exchange mailbox. I don't even care about this evolution-
data-server binary. Nor do I care about any other but the Camel library.

Yet ... I have to do all these insane things just to get the Camel
provider of evolution-exchange working on Maemo.

Conclusion .. all this coupling with Evolution and Evolution Data Server
is making it harder for application developers to actually *use* the
provided functionality.

 No, I don't think that is a good idea either.


   If you find large bits of code that are only used in camel and are
   currently in libedataserver, I'd propose moving them into camel:
   libedataserver could do with slimming down.
  
  For example EMsgPort, is that used by something else but Camel?
 
 By the magic of grep, libedataserverui/e-passwords.c uses e-msgport.c.
 

-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers