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