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

[PUYDT Julien <julien puydt laposte net>]

On mer, 2004-04-28 at 03:47, Rodney Dawes wrote:
> 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.

Quite true.

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

Look in lib/contacts: the api declared in gm_contacts.h is implemented
in gm_contacts-eds.cpp through eds, and in gm_contacts-gm_conf.cpp
through nothing yet (it is stub code to get gm to compile without gnome,
to help the win32 port). That means there is much more code than should
be (if only gnome would mostly run on win32...)

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

That is a *very* good question, and in fact, instead of wondering
whether to use this or that technology, we should perhaps write how we
would like to use gnomemeeting (ie: what api do we want to 'export',
whatever that means).

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

That would indeed be more logical: there's a --disable-gnome swith, it
should also be a --disable-eds.

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

Bonobo doesn't run on win32 as far as we know, and isn't kde-friendly,
so that means if we go for bonobo, we'll have to add yet another
implementation of that too.

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

DBUS api isn't fixed yet, and the implementation isn't ready either ; we
don't know if it will run on win32, but at least that will be
kde-friendly. This is going to be interesting, but isn't yet: wait and
see.

> > - commanding GM through a local socket (the XMMS method) : will work
> for
> > both GNOME and KDE, portable : DEFAULT CHOICE until DBUS is ready.
> When
> > 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.

Quite true, but at least it will work for gnome+kde+win32...

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

That is indeed what I wonder too. The im program could ask a running gm
what the local url is (gm will be able to answer that easily, and that
should be part of the 'exported' api). But what if gm doesn't run?

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

I have no problem with gnome, but being kde-friendly, xfce-friendly,
e-friendly, fvwm-friendly, fluxbox-friendly and win32-portable is also
nice.

How should gm be used from the outside (sort of like an exported api)?

Snark