Looking for well-known service names

[Jim Carter]

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
something special.

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
integrator.

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:

org.freedesktop.service.media
    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.)

org.freedesktop.service.image
    show(URI, Window)
	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.
    progress(state, errormessage)
        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.)

org.freedesktop.service.email
    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.

org.freedesktop.service.chat
    (Different chat services, including VOIP, may or may not have 
    separate service names subordinate to this one.)
    connect(service)
        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.
    presence(state)
	The user is advertised as being available, out to lunch, etc.
    chat(peer, window)
        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.)

org.freedesktop.service.authenticate
    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.

org.freedesktop.service.crypto
    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.

org.freedesktop.service.database
    sql(database, query)
        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)