Proposal and RFC: DAL, the Desktop Abstraction Layer
Jamie McCracken
jamiemcc@blueyonder.co.uk
Fri Jan 14 03:37:13 PST 2005
<moving this to dbus/xdg lists>
Havoc Pennington wrote:
> As Mike Hearn says, I think what you described is simply what the D-BUS
> session bus is for. There's no need that I see for an additional DAL. If
> D-BUS doesn't do this as-is we need to change D-BUS so it does. This is
> the whole point of D-BUS.
>
So would you consider adding profile support to Dbus?
To sum up, profiles (as in Bluetooth Profiles) allow you to define a
common interface with methods and events which would be publically
documented. Services can implement any number of these profiles.
Profiles are identified by an integer based ID (enum it). A sample
simplified email profile might look like:
<profile ID="1345">
<name>email profile</name>
<version>1</version>
<methods>
<method name="SendMail">declare params here etc</method>
<method name="NewMail">declare params here etc</method>
</methods>
<events>
<event name="OnMailReceive"/>
<event name="OnMailSent"/>
</events>
</profile>
Why is it needed?
Seemless interoperability is the goal. If I want to be able to remote
control any compliant email app without knowing the specifics of each
implementation there is currently no way to do it - they are all
arbitrarily defined interfaces. I cannot also lookup easily for such a
service and it wont necessarily be obvious from looking at the dbus
service name either (how would I get a list of all available email
services?). This is where profiles come in handy - as long as we can
query which service supports what profiles it would be fairly easy to
implement. A service can implement a number of profiles too. The event
notification that DAL is being proposed for is also covered by these
profiles.
How it would fit in with Dbus?
Dbus already provides everything we need to implement this with only the
addition of a means to query the services for what profiles they
support. As profiles are publically documented there is usually no need
to introspect a profile's methods/signals.
How would it be implemented?
Dbus already uses a service description file so it would be handy to
store what profiles a service supports there - this would make querying
very easy to implement.
How are profiles allocated?
Profiles would need to be defined and agreed upon by freedesktop. We
obviously dont want any repitition in profiles to avoid bloat. The end
result should be that a developer only needs to familiarise himself with
the profiles hes interested in and not worry about the apps/services
that implements them.
jamie.
More information about the dbus
mailing list