Looking for well-known service names
jimc at math.ucla.edu
Sat Mar 8 10:01:27 PST 2008
I have just written the "Meow Media Player" using GStreamer as the
backend, taking about 2 hours to create a first draft as a shell
script and about 15 hours to learn to build a Python GUI with Glade.
Now I want to Do the Right Thing and make it available to
media-relevant applications over the D-Bus.
For example, suppose KPresenter or OpenOffice_org Impress is presenting
a slide show where each slide has voiceover, or suppose you have a music
or video library organizer separate from your player (the right way, in
my opinion), or suppose your web browser encounters a video. Although
creating a GStreamer backend for each application is not too onerous, it
would be a lot worse with the Xine, Helix or XMMS plugin frameworks and
outrageous if all four had to be supported. Hence you want the
application to send a D-Bus method call to the user's preferred player
(like Meow) that will function successfully in the particular user's
context, i.e. availability and political correctness of codecs, and
which audio backend is to be used: OSS, ALSA, ESD, PulseAudio, or
What is the Well-Known Service Name, Object Path, and Member Name that
the applications will naturally call to have a file played, which Meow
should make itself available on and should place in
/usr/share/dbus-1/services/meow.service ? Or to put it another way,
where is the equivalent of /etc/services (IP port assignments)? Or the
equivalent of the Bluetooth interoperation protocols such as OBEX or,
in my case, A2DP?
I don't think Name=org.helixcommunity.HelixDbusServer is what I should
use. nu.mine.otter.meow does belong to me. But neither of these names
really qualify as "well-known", and I really doubt that any relevant
application thought to include either name as its D-Bus destination. And
for method names, do you think "hairball" would be a good choice for the
method to play a file? I thought not :-) Integrated suites with a
common management, such as org.xfce, often use D-Bus in a shared
namespace; and the Maemo distro has gone whole hog into D-Bus, having 71
service files, but there's no chance that my media player could be a
part of any of that because the names are all known only to the suite's
By analogy to Bluetooth, I would suggest that the D-Bus team sponsor a
set of generic interfaces (referring to the service name, object path,
and set of members (methods and signals)). To get the process started
I'll make some suggestions:
play(URI, window, visualize)
URI (string) tells what to perform (local file or URL).
Window (int?) is an X-Windows ID; if absent the player will
open a window by itself, if visual output is relevant.
Visualize (boolean) asks the player to make a decorative visual
display representing the audio, if it's capable of that.
pause(), stop(), next(), prev() control playback as with AVRCP.
progress(state, position, duration, errormessage)
Signal sent once a second giving progress in the performance.
State may be buffering, playing, paused, done, error. Duration
is the player's estimate of how long the track lasts (in
seconds), and position is how many seconds have been performed
(not counting buffering or pauses).
(Maemo does something similar to this, under their com.nokia name.)
URI (string) tells what image to show (local file or URL).
Window (int?) is an X-Windows ID; if absent the program will
open a window by itself.
Signal showing progress; state may be downloading, rendering,
done, or error.
(Maemo has a service like this, but surprisingly it's not on D-Bus.)
send(recipient, subject, body)
The e-mail client opens a composer window primed with the given
message parts, some of which can be zero-length strings.
(Different chat services, including VOIP, may or may not have
separate service names subordinate to this one.)
The chat manager obtains the user's credential and makes a
persistent connection to a central server. There could be more
than one server using the same protocol (e.g. XMPP on jabber.org
and also Google Talk) and the service ID or object path would
need to distinguish them. Some users with imprudent security
cache their credentials, and the chat manager connects
automatically to all the servers at login time.
The user is advertised as being available, out to lunch, etc.
Establishes a conversation. The peer (person you're chatting
with) would have to be identified using the protocol's own
syntax, e.g. phone number for VOIP. A really spiffy chat
manager could accept a key=value pair, look it up in the
addressbook table via D-Bus, extract the field named for the
chat protocol, and use that. (Or with normalized tables, it
would join the contact identity table and the protocol address
table to map key=value and protocol/server to a user ID.)
credential(type, principal, challenge, window, description)
This method handles the user interaction when authenticating.
The ideal is if it were a front end for SASL. Although in
password authentication the user's password is sent to the
server, Kerberos, RSA and smart card authentication involve
doing arcane transformations of a challenge string sent from the
server and sending back the result. If the user has to be asked
for a password, or to insert a smart card, this can be done in a
window provided by the client, or the service will open a window
by itself. The "principal" is the user's identity name as known
on the server.
encrypt(keyring, key, infile, outfile)
decrypt(keyring, key, infile, outfile)
The cryptographic service figures out the type of encryption,
obtains the key, reads the input, encrypts or decrypts it, and
copies it to the output. For streaming content, either file
could be a named pipe (FIFO) that the client reads or writes.
This is for a Personal Information Manager backend, though other
databases could be used in addition, and the specification would
have to include the database, table and field names and
semantics, as well as the returning format. Suggested:
field=value\n for each field in the result, and multiple records
(we hope not many) separated by blank lines. It may make more
sense to identify the database in the object path.
query(database, table, field, value, matchtype)
This is an alternative if real SQL is unpalatable: in that
database (e.g. your PIM database), in the given table (e.g.
addressbook), find the record(s) where that field (e.g. email)
matches (e.g. exact or substring) the given value.
update(database, table, record, flags)
Another alternative to SQL for updating a record. "Flags" tells
whether to insert if the record's primary key does not already
exist, to (attempt to) insert multiply if it does, to replace
entirely, or to replace fields that are non-null in the incoming
record, leaving null ones alone.
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc at math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
More information about the dbus