Re: [GnomeMeeting-devel-list] GnomeMeeting in the very near future

On Hën , 2004-04-26 at 17:18 +0200, Damien Sandras wrote:
> Hello to all,
> You all know that I was working on Evolution (more precisely Evolution
> Data Server aka E-D-S) support in GnomeMeeting.
> However :
> -1- I'm a bit bored to do it for now
> -2- Some people have complained that they couldn't compile CVS anymore
> because it required one more dependancy

They can't compile it, because they want to use the most bleeding-edge
software, but not update other pieces of software when it needs newer
versions? That is all I've gotten out of the complaining. I've not seen
anyone trying to provide a real solution. Just people bitching and
complaining that they have to build something else new.

> -3- The Multitel guys have started working on GM WIN32 again and thus
> needs something that always compile

Why can't win32 have something that will always compile? They aren't
going to be using e-d-s anyway, so it should get #ifdef'd out by the
compiler in the first place.

> -4- People are asking me for a way to be able to interoperate with GM

OK. What does "interoperate" mean here? There are many ways to
interoprate with gnomemeeting already. What specifically are people
trying to do?

> As a consequence, I will :
> -1- Modify CVS so that E-D-S support is only compiled in if you pass
> --enable-eds to configure, and if GNOME support is also compiled in.
> That way the default GNOME builds won't have E-D-S support and the
> non-GNOME builds won't have it either.

It should be enabled by default and people can do --disable-evolution
or whatever, to get a gnomemeeting build without a local addressbook.
They can still use ILS but not keep any local contacts. If people
complain about missing features, their complaints can be re-directed
to the packagers, since that is where the problem actually lies.

> -2- Work so that GM can be used by other programs.
> About -2-, we have 3 ways of doing things :
> - bonobo support : will work only for other GNOME programs,
> non-portable : REJECTED

REJECTED? We already use bonobo. There's no real need to actually embed
gnomemeeting's UI in some other application. So "portability" isn't an
issue, since all of the non-ui bits are basically portable, and afaik,
all work on win32.

> - DBUS support : will work for both GNOME and KDE, I don't know if it
> portable or not, but it is not ready yet : POSTPONED

What does this mean exactly?

> - commanding GM through a local socket (the XMMS method) : will work
> both GNOME and KDE, portable : DEFAULT CHOICE until DBUS is ready.
> DBUS will be ready, I will make DBUS the default method for the
> GNOME-enabled GnomeMeeting and the local socket method for the
> GNOME-disabled GnomeMeeting.

Ugh. More custom protocols for doing IPC is something we don't need
really. What is keeping you from using ORBit/Bonobo for this? It is
portable. As portable as using other unix sockets is anyway, since that
is all that ORBit does for the IPC communication. It just happens to
already be a full-fledged standard that is widely used for doing things.
The GNOME build is going to depend on bonobo anyway.

> I will also work (perhaps) on a GAIM plugin allowing to start a
> videoconference from GAIM if the remote party is also using GM.
> Completely non-standard, but that will evolve in something more
> once we have ported GM to OPAL. Craig think it is not fully ready yet.

Out of all the things you listed, this is probably the easiest to do in
reality. Though, the plug-in would presumably be connecting to ILS or
something to determine whether or not the other user is using
gnomemeeting. And I guess you need to get a callto: url or e-mail or
some other reliable bit of information that you can actually look for
in the ILS server, so you'd probably be using evolution-data-server for
that also, no?

All in all, I think the general fear of using gnome 2.6 is causing all
this commotion, and evidently it is causing some seemingly bad decisions
to be made. I understand why you are thinking this way, though. So, it
is not too bad. But I do think a lot more thought needs to be put into
what to do for 1.2 and how to do it, before you dive in doing something
that you might regret and end up having to rewrite later on shortly
before code freeze for gnome 2.8 or something like that. The GNOME in
GNOMEMeeting doesn't stand for "BeOS". It stands for GNOME. If you want
to also be portable to other platforms, like win32, then so be it. But
on unix, where we are depending on GNOME, we should integrate with it as
well as we can. Sometimes that means that we need to use newer
technologies than what a 3 year old distro might ship. We shouldn't keep
developers from using the stuff they need just to keep 3 users happy by
allowing the packagers to keep something building on a 3 year old
distribution of linux.

-- dobey

Attachment: signature.asc
Description: This is a digitally signed message part

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