[Portland] Current plan summarized

[Jon A. Cruz]

On Mar 22, 2006, at 9:44 AM, Dan Kegel wrote:

> On 3/22/06, Jon A. Cruz <jon at joncruz.org> wrote:
>>>>> ... standardizing IPC means you have to make all those final
>>>>> decisions about:
>>>>> ...
>>>>> -) Perhaps clients have to read a config-file to look up the  
>>>>> socket
>>>>> name. Where to find the config-file?
>>>>
>>>> Perhaps Zeroconf for discovery?
>>>
>>> No, thanks.  Let's keep it simple...
>>
>> Have you actually compared the complexity of using Zeroconf with
>> manually implementing the equivalent functionality?
>
> Have you considered whether we need discovery at all?
> A hardcoded socket name might do just fine, and oddly enough,
> that's what dbus uses for its system bus; see
> http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus- 
> types


Yes, I have. That's also why I asked about it.

However... that appears to not quite be a hardcoded name, but a  
hardcoded fallback name. And that's only on the system message bus,  
not the login session message bus.

In that latter case it uses first an environment variable and then a  
fallback to a X window property for discovery. (and would a login  
session type focus be needed? I know I often log in locally with one  
set of usage apps and remotely with another, with various desktop  
sessions running simultaneously. Even my gtk+ theme is different for  
remote sessions)

So even though dbus does have that hardcoded fallback, it appears to  
have a "discovery method" involved to allow connection to something  
other than that hardcoded value.


Using some general discovery method frees things up a bit as far as  
being tied to a specific implementation goes. I think the System Tray  
protocol is a very good example of this in action.

http://standards.freedesktop.org/systemtray-spec/systemtray- 
spec-0.2.html#locating

It implements things with actually a fairly minimal set of details,  
yet allows for a vary robust experience including allowing for  
switching providers on the fly, recovering from crashing providers,  
etc. It also works appropriately for local logins, remote X11 logins,  
remote X11 apps/shells, and various VNC scenarios.

I think the various factors involved in the system try case make  
using an X11 selection a fairly good solution for its needs.  
Identifying the various factors around the DAPI use cases will  
probably make finding its appropriate solution that much easier. And  
considering different possible technologies and approaches can help  
arrive at a better solution in the long run.