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