Where to start

[John (J5) Palmieri]

On Sat, 2005-03-26 at 15:21 +0000, Tony Houghton wrote:
> In <1111845362.15388.32.camel at localhost.localdomain>, you wrote:
> 
> > On Sat, 2005-03-26 at 13:25 +0000, Tony Houghton wrote:
> > 
> > > I'm writing my program as a main application and a separate config
> > > applet. The capplet needs to be able to send messages to multiple
> > > instances of the main application.
> > >  I know gconf would make that easier
> > > on the face of it, but using my own storage scheme makes it easier to
> > > manage the storage of arbitrary named profiles. Also, the main program
> > > needs to be able to start the capplet or, if it's running already, send
> > > it a message to start configuring a set of options.
> > 
> > You can use dbus activation to start services.
> 
> How can I find out more about that? It's yet another aspect of dbus I
> can't find documentation for.

Actually it is called starting services now and not activation but in
0.22 it is still called activation.  The dbus specification has all the
info you need to know about activation.


> > What version of d-bus are you using?  The glib bindings have changed
> > tremendously in CVS. 
> 
> 0.22 in Debian unstable.

At Red Hat we ship 0.22 with RHEL-4 but we don't recommend anyone
writing software to it (it is there for infrastructure right now).  Of
course that is in a perfect world.  Just understand you will have to
port your app at some point and depending on how complex it is it could
end up being a pain.  Look at both the old API's and the new ones and
try to plot a course that will minimize the work you will need to get
done (like not littering your sources with dbus calls, keep them
consolidated).

> > > Or do I have to explicitly start the service name? I can't see how to do
> > > that. And if I do, is it OK just to start it in the capplet, while the
> > > main instances only have to register their proxy once and can still
> > > continue to receive messages OK, no matter if the service is stopped and
> > > restarted?
> > 
> > This is a complicated issue.  For your use I would suspect that you
> > would request a name for your capplet and not for your multiple instance
> > app since d-bus names are unique on a bus.  You would then have you app
> > subscribe to signals from the capplet.
> 
> Good, I was sort of hoping it would work that way. But how does the
> capplet request a name? It doesn't seem to be supported in 0.22's glib
> bindings. 

You don't request names in 0.22 the nomenclature was changed a bit
later.  In 0.22 you acquire services. If Debian doesn't ship with a
dbus-doc package I would suggest getting the 0.22 tarball, compiling it
and reading the generated specification file in the docs directory.

> And can I simply hook each instance up to that name with a
> DBusGProxy without worrying about whether the capplet gets stopped and
> restarted, or will all the instances have to keep track of what owns the
> name? If so, how is that ownership transferred?

For 0.22 the glib bindings are mostly useless except for the mainloop
integration.  I would just use the standard lowlevel dbus API.

> > If you are going to use the dbus from CVS or the one I should be
> > releasing soon (0.32) which I highly recommend there should be some
> > sample glib binding code in the tarball.
> 
> It would be nice to be able to just use that if it's improved, but I
> think I need to support 0.22 as well to make sure my application is more
> accessible. I wouldn't be surprised if 0.22 gets frozen into Debian
> sarge (the next stable). 

Well here's the thing, not only are the glib bindings improved, they are
actually useful in the latest DBus thanks to Colin Walters.  It is up to
you what you want to target but it is my thought that unless the
application is essential to the operation of a distribution any new
development should be targeting the 0.3x series.

--
J5