Proposal and RFC: DAL, the Desktop Abstraction Layer

[Jamie McCracken]

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