Re: [Gaim-devel] gaim-remote changes

[Christian H. <ch...@gm...>]

I have a lot of experience with D-BUS, and have used it extensively in
projects (as well as having contributed some fixes to it), so I'd be
glad to help anyone who plans to work on this. It's something I was
meaning to work on, but obviously, I don't have the time. There are a
few things to beware of. First, Havoc makes no secret that the API is
unstable right now. That hasn't been a big deal yet, except the
upcoming D-BUS 0.30 release introduces a new typing system, and
removes some types (such as the NIL type). This will be important to
realize.

Imho, the quickest way to do this would either be to move everything
to GObject and use the bindings there, or to write a small
compatibility layer that uses the gaim signal API and small
registration functions to set up the necessary bindings. It's actually
not too hard, especially if you write some decent wrapper functions.
This is what I did for Galago.

Anyhow, let me know. Perhaps I could set aside some time soon (after
next week probably, girlfriend is spending spring break here) to write
the bindings.

Christian

On Fri, 04 Mar 2005 13:24:45 -0500, Sean Egan <sea...@bi...> wrote:
> On Fri, 2005-03-04 at 09:48 -0500, Luke Schierer wrote:
> > I'm fairly sure that gaim-remote is different from a ui, reguardless
> > of what its original intention was.  This is particularly true, though
> > not exclusively true, in the gaim-remote we ship with 1.x, which is
> > almost solely a aim uri handler.  It is also particularly true now
> > that gaim-remote talks to the remote contorl plugin rather than to the
> > core itself.  My objection would be the introduction of a gtk
> > dependency to a core plugin, not to assuming that gaim-remote is
> > manipulating a separate gaim with a "real" ui.
> 
> Long E-mail follows.  I've CCed Ayan Chakrabarti who recently had a
> gaim-remote patch rejected as well.
> 
> After rejecting this patch, I thought to myself whether I'm being too
> conservative with gaim-remote, allowing its original intention stand in
> the way of practical uses of it.
> 
> The original idea of "core/ui" split was that the core and the UI would
> talk to each other with the core/ui protocol (CUI) through sockets. I
> created gaim-remote as a minimal UI that would connect to the core,
> manipulate it in a few simple ways, and disconnect. Because of this
> design, I reject patches that attempt to manipulate the interface or
> manipulate the core in a way that, while suitable for gaim-remote, is
> unsuitable for a core-ui protocol in general.
> 
> Since then, "core/ui split" has taken on a totally different meaning and
> having the core and the UI communicate through sockets (which would
> still be cool), is less of a priority and the core-ui protocol's most
> prominent use as far forward as anyone can really see is gaim-remote.
> 
> Further, my ideologies about how gaim-remote should be used are keeping
> gaim-remote from doing anything more useful than interpreting aim:
> URI's.
> 
> Let's suppose that gaim-remote should change from a minimalist
> single-command line user interface (what I've always viewed it as) and
> turn into a convenient way of manipulating an existing Gaim session
> (what others actually want to use it as). I'd say this shift of focus is
> a probably a good idea. However, I'd argue against extending or misusing
> the CUI protocol.
> 
> The CUI protocol was designed for manipulating the core from a UI and
> vice-versa, not for manipulating existing Gaim sessions. Off the top of
> my head, there are two major disadvantages to using the CUI protocol for
> this latter purpose:
> 
> 1) Extending the CUI protocol is hard. Most of the patches I get to
> gaim-remote simply pass a string of human-readable text back and forth
> over the socket. People don't realize, partly because a single string of
> text is how "gaim-remote uri" works, that the CUI protocol is a binary
> protocol and should be far more complicated than a single string.
> 
> 2) Using the CUI protocol is hard. gaim-remote is, as far as I know, the
> only implementation of the CUI protocol is gaim-remote, despite that the
> functionality of manipulating a Gaim instance would be insanely useful
> all over.
> 
> The proposed solution: DBus.
> 
> As much as I hate the hype that tends to come with buzzword-type
> technologies like DBus, and have criticized people for said hype, DBus
> seems to be wholly appropriate as a replacement to CUI for gaim-remote.
> 
>  Because it's a freedesktop.org standard with bindings to GLib, Qt, C#,
> Python, and assumingly many more as DBus matures, it makes it 1) easy to
> extend: just make library calls instead of manually manipulating a
> binary byte stream, and more importantly 2) easy to use. It's a
> Freedesktop.org standard for IPC; there's no need for an application
> that wants to jive with Gaim to learn a new protocol or link against a
> Gaim-provided library.
> 
> Also, it completely frees of us the need to handle sockets in /tmp and
> do all sorts of stuff that we tend not to do too well anyway.
> 
> Further, gaim-remote could be replaced with a trivial shell script that
> calls dbus-send. shell script might not be the best way to do this, but
> it's possible. And that's cool.
> 
> I don't know very much about DBus. Exposing a DBus interface certainly
> *seems* an appropriate solution to the problem. My MP3 player, muine,
> uses DBus for remote control like this. Executing:
> 
>  dbus-send --session --dest=org.gnome.Muine --type=method_call
> "/org/gnome/Muine/Player" org.gnome.Muine.Player.Next
> 
> goes to the next track, for instance. So that certainly implies that
> gaim-remote is possible implemented over DBus. Someone should do some
> research to the limitations of DBus and see if any are too restricting
> for gaim-remote. Barring that, I think someone should give this a whirl.
> Using the GLib bindings for DBus, I strongly doubt it would take very
> long to hack together. I'd really like to see this happen.
> 
> -s.
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>