Proposal and RFC: DAL, the Desktop Abstraction Layer

Jamie McCracken jamiemcc@blueyonder.co.uk
Wed Jan 19 10:08:26 PST 2005


Jamie McCracken wrote:
> Havoc Pennington wrote:
> 
>> On Wed, 2005-01-19 at 16:03 +0000, Jamie McCracken wrote:
>>
>>>> You should get a list of all services that export a particular 
>>>> interface
>>>> and then activate the service you want.  We should fix D-Bus if it
>>>> doesn't do what we want or create another daemon that keeps track of
>>>> these things.  A spec which aims to be a standard should not try and
>>>> workaround deficiencies.
>>>
>>>
>>> Thats what I asked for earlier in this thread but Havoc is reluctant 
>>> to implement that and not wishing to upset Havoc I accepted the 
>>> compromise of multiple services for that.
>>>
>>> I agree its much better to use interfaces here than services after 
>>> all an interface is an agreed well defined contract so it seems 
>>> pointless to make a service a well defined contract too in those 
>>> cases. I should also add that only public (pre-defined) interfaces 
>>> should be exported as you suggested (theres obviously no point asking 
>>> for a propriety interface).
>>
>>
>>
>> As soon as someone explains how an application (rather than an object
>> instance) can implement an interface, then I'm happy to listen.
>>
>> In the meantime you are suggesting the equivalent of this function:
>>
>>  bool process_implements_gtk_editable (pid_t process_id);
>>
>> If you can explain how that makes any sense *at all* then I'm all ears.
>> Processes are not editable text fields.
>>
>> Havoc
> 
> 
> Firstly I'm not insisting on this functionality - Its okay with me to 
> have it implemented at the service level though I *prefer* to have it at 
> the interface level as thats more consistent with what im used to namely 
> COM (and Corba too) and it avoids all the confusion between interfaces 
> and services.
> 
> A COM server is an application and it implements interfaces. The concept 
> of object instances is not really relevant because the COM server's 
> interfaces are a contract and you dont have any knowledge of whether any 
> actual instances of the underlying objects exist. When a COM server is 
> activated all its interfaces are available - its not like some 
> interfaces are only available if a document is open rather its a case of 
> the COM server saying I dont have an open document therefore I cant 
> perform function X if an instance does not exist (EG if I tried to do a 
> word search and there was no open document, the text editor's search 
> method should return an error indicating there's no doc open). In 
> essence that means the interface is a separate object to the actual 
> object that performs the function on it. If it was not then obviously 
> you would seg fault if you called a method on an object that was not 
> instantiated. That does not and should not happen in COM so should it 
> not be the same with Dbus?
> 
> 
> jamie.
>  

I also forgot to add that a com server is an object too. If I use VBA to 
remote control one it treats the com server as if it were an object. 
Therefore one could argue that the application itself is an object instance.


jamie.

> 
> 
> 



More information about the dbus mailing list