Philip Van Hoof spake unto us the following wisdom:
> As we all probably know has the GNOME community committed itself to the
> keyword "Integration between different desktop application".
For the record, we (the Gaim project) are not part of the GNOME commu-
nity any more than we are the KDE community or the XFCE community.
Smooth integration with each of these environments would be (and is)
awesome, but it is not priority one. As Luke noted, there is a limited
amount of talent and effort available to be applied to Gaim, and thus
far the portion of it allocated to desktop integration has been rela-
> As a result you can, on a recent GNOME desktop, for example view the
> appointments you have when you click on the Clock-applet. Another
> example is the tight integration with GnomeMeeting and the Evolution
> My opinion is of course that such an integration is a good thing.
Yeah, it's great if you care about gnomemeeting, evolution, or the gnome
> GAIM, however, does not easily integrate with other desktop
> applications. There are proposals to improve the situation but it looks
> like they have not yet been accepted? http://www.chipx86.com/gevolution/
This is part of the regular gaim distribution and has been for ages.
I'm not sure why you think it isn't.
> Where is the current 'idea', the 'concept' of GAIM heading? Are the core
> GAIM developers interested in this type of integration and cooperation
> with other applications? And if so, what is the status?
Sure, we're interested ... but we're not applying a large portion of our
time to it, because there are more important problems to solve. A quick
browse of the gaim-devel mailing list would give you an idea of the sort
of features and infrastructure we're working on and considering impor-
tant these days.
> I saw, for example, that you need to utilise a gaim-remote commandline
> tool to make Gaim do some common operations from within another
> application. My first thought was: "how can that still be true these
> days?" and "but...there's CORBA and ORBit, no?!" It even looks like it's
> using manual sockets-code (much like how xmms has remoting?). Wtf?
What do you mean, "wtf?" My first reaction is to take this as an indi-
cation that you don't know jack about IPC or software design, either
one; for your benefit I will withold that judgment and give you a chance
How is CORBA in general, or ORBit specifically, a better choice for what
gaim-remote does? (I speak not of the specifics of gaim-remote; it has
quite fallen by the wayside recently and has a rather anemic functional-
ity set -- this is not, however, tied to its method of communication.)
Applications have the choice of either invoking gaim-remote to communi-
cate with gaim (which, despite your obvious condescension, is a good way
to do the communication -- maybe you don't use shell scripts, but some
people do), or of communicating with gaim directly via the gaim-remote
socket using libgaim-remote. These methods are not worse than CORBA in
any way, they are merely different. In fact, knowing what I know about
CORBA, I would be inclined to say that they are significantly better in
In short ... what is the problem here? You are aware, are you not, that
ORBit communicates via sockets?
> I understand that platform independency is a nice thing. A solution for
> that, however, is to create platform dependent drivers or interface-
> implementations. For example.. say the list of available buddies would
> be a store that is to be accessed using ORBi, or a lot like the
> evolution-data-server. So it becomes a service. A problem might be that
> ORBit doesn't work on all platforms. You could, however, make the
> accessing this data abstract, and provide one implementation that uses
> XML and another implementation that will connect to an ORBit-server. And
> perhaps yet another implementation that will connect to some .NET thing
> on Windows.
Sure, and we've been working on similar abstractions in other areas of
gaim; again, if you bothered to take the time to look at the gaim-devel
mailing list, this would become immediately apparent. Again, if you
bothered to look at the gaim source you would notice that, like the
gevolution plugin, gaim-remote is a plugin shipped alongside gaim --
there is nothing preventing anyone from implementing an alternative com-
munication mechanism, and in fact it is already possible to control gaim
in quite sophisticated ways via the 'send' functionality of Tk (see
The bottom line is that, given the limited amount of developer time and
talent available to be applied to gaim, such alternative services have
not been a priority.
> The advantage would be that any other GNOME desktop application could
> also connect to that ORBit-server to get information about the current
> available buddies. Which would in turn ease integration with other GNOME
Any gnome application can currently connect to the gaim socket or via
the tk send interface. Neither of these are particularly difficult to
> Note that I'd be interested in helping technically. I am not, however,
> interested in endless discussions about how greate platform indendency
> is and how impossible it is to support nice things without breaking that
> platform independency. It's not impossible. Nothing is impossible. And
> yeah, so what if that means a lot of work? There is time ... Oh and
> everything that is well written is maintainable. Maintainability is not
> related to source-quantity per s=E9. My opinion is that it's more related
> to source-quality.
It's great that you'd like to help out; feel free to get involved. We,
however, are not interested in endless spoutings of how great a given
technology is based on ignorance of the alternatives
Regarding maintainability ... I'll assume you've never maintained a
project of any size. Quality is certainly a factor, but quantity is, as
well. Bit rot does happen in any project which is making nontrivial
forward progress. Maintainable and affordably maintainable are two
entirely different concepts.
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764