thoughts(?) on interconnecting dbus on 2 systems to get anything useful...

[L A Walsh]

Simon McVittie wrote:
> On Sat, 17 Jun 2017 at 20:30:58 -0700, L A Walsh wrote:
>   
>> That leaves system-bus traffic on the
>> linux-box that needs a way to connect back to the winbox's
>> system-bus.
>>     
>
> This is not something that will ever be supported. The system bus is
> specifically per-machine; sharing a system bus between two machines is
> never correct.
>   
---
    Even if you want the two machines to function as 1?

    What is the system bus used for?  I mean, I start it on
my linux and on my windows box (under cygwin), but I'm not sure what
they do that the session bus isn't handling.
> The session bus *might* be possible to distribute between machines, but
> I don't think that configuration will ever be reliable or predictable.
>   
    Maybe not.  But that would indicate a need for something that
>   
>>   As a parallel to my situation, if you think about people with
>> remote linux systems (android based), wanting to connect to services
>> of linux systems "in the cloud", there might also be situations
>> where system buses of client-server systems need to communicate or
>> do some temporary bridging (with filtering being 'optional').
>>     
>
> If a particular application or use-case needs to communicate between
> the system buses of two different machines, then that is something for
> that application to solve.
>
>   
>> Allowing remote
>> users on a remote handheld or tablet system (might be based on some
>> OS other than linux) to 'cloud-connect' to server-systems might
>> allow clients to reserve or attach server resources (compute,
>> graphical rendering, disk, fax, media-streams, etc) with actual
>> content coming back via higher-bandwidth channels.
>>     
>
> The state of the art for doing this is to typically to use VNC, Spice,
> RFB or a similar protocol to put as much as possible on the server,
> with the client being merely a terminal or viewer (in the sense of
> <https://en.wikipedia.org/wiki/Computer_terminal>). This would
> typically mean that all D-Bus communication happens between processes
> on the server.
>   
----
    The state of the art 10-20 years ago allowed for Distributed messaging
between machines using CORBA which was preceeded by "DCE" (something still
used by Samba).  A non-adopter was Microsoft which used DCOM.  DCOM still
survives, but CORBA didn't seem to.  It used names for applications with
with name numbers and dots in them and was arranged hierarchically. 

    It looks like the naming that DBUS uses is similar.  CORBA used ORB
for applications or "components" to talk to each other -- either on the same
machine or on a different one. 

    See more on this @
http://searchsqlserver.techtarget.com/definition/CORBA and
http://searchmicroservices.techtarget.com/definition/Object-Request-Broker-ORB

    Or just google for Distributed CORBA.

    Since DBUS looks very similar to what CORBA was using (I thought it 
looked
familiar), I think I was expecting it was an evolution of that, but it looks
like it was a reimplementation.

    Also looks like Microsoft, at least, agreed to a "gateway" between
CORBA and the "Component Object Model" (COM), so cross architecture 
communication would be possible.

    Maybe DBUS could use a gateway approach to send inter-application 
messages
across machine boundaries?

    It looks like the reliability issue was solved a decade or more ago
(looks like the docs were from 2006)  I thought I remember seeing CORBA
implementations back in the 1990's... hmm.

    Maybe unix code from that project could be ported to linux...dunno.