Re: [Evolution-hackers] Port my apps to 2.0

On Wed, 2003-11-26 at 12:50, JP Rosevear wrote:
> On Wed, 2003-11-26 at 13:47, Ronald Kuetemeier wrote:
> > Hi Guys,
> > I will be looking into porting my apps, send mail from alarm ..
> > freebusy, to evolution 2.0.
> > I have a few questions before I start:
> > 
> > Which cvs tree should I use, evolution or evolution-data-server?
> Depends what it does.  e-d-s contains what used to be the wombat and
> cal-client and e-book.  We might be interested in integrating some of
> these patches as well, do you have a longer description for each?
Sure, look at the patches to this list I send from the 1.X time frame
on. Seriously, I have send the patches, but have no interest to push
them into the main code. Since I believe not everything has to be
supported by the main apps, if there is only marginal user interest. And
for something like sending mail from an alarm and freebusy info via dav
to a web-server that seems to be the case. I will send the patches
against 2.0. Some companies are running evolution with my patches, and
they know what they are doing. But most users are more interest in
working with the system, while a few have switched over having the
system work for them. Any more management talk :-)? 
> > Do I still need to extend Evolution-Component and get the Composer from
> > the shell/mailer, i.e. run it under the shell like it was necessary in
> > 1.4.X? Or did anybody provide a generic way for 2.0 to get components,
> > if so please explain? I would also like to use the Composer from
> > OpenOffice via a Java/C++ extension that way.
> Unfortunately yes, but the shell simplified a great deal (7 methods
> total I think now).  You can also launch the composer via corba.
Yeap, you can and actually I do it in 1.4.X. But if you don't get the
interface from the shell/mailer the results are undefined, i.e it
crashes because of camel run time dependencies. So I changed the mailer
component to return the interface, which then runs fine. The problem is
if the shell is not running. I have to start the shell, get the mailer
component, get the composer. See my patch to the list for some "ugly"
way of waiting for the shell to start. The way the calendar uses it to
send meeting request and .. only works because it runs under the shell,
basically doing the same thing. But out of memory apps interfacing with
the composer have to do it a little different. There was also a mail
from Not Zed explaining why and a rough design, which I just implemented
for my purpose and now realized, hey I can use that from OO. Actually I
have a program which generates the code and I have to teach it how to
use evolution.
> > On a site note. I gave a talk about evolution last month and got
> > "grilled" about the groupwise connection. The person asked was an admin
> > who works for the county I live in, asking for the county which already
> > uses Linux. I pointed him to this mailing list and the cvs entry, with
> > the comment that it seems somebody is working on it and there might be a
> > chance for official 2.X support. Just a friendly comment that there
> > seems to be commercial interest in it.
> Rodrigo is currently working on the groupwise support for the calendar.
Cool, hope they read the list.

> -JP

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]