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

[Philip Van Hoof <spam pvanhoof be>]

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