How about employing <anything> (now: TLS, later?)

L A Walsh dbus at tlinx.org
Sun Jul 15 22:30:53 UTC 2018


Thiago Macieira wrote:
> On Sunday, 15 July 2018 13:16:02 PDT L A Walsh wrote:
>   
>>> Because AllJoyn and D-Bus have different objectives.
>>>       
>> That part shouldn't make a difference.  Having a car that can drive to
>> New Mexico doesn't mean it should be different from a car that can drive
>> to Florida (presuming neither is a local trip).
>>     
>
> No, but a car and a train are quite different from one another.
>
>   
Certainly, but if the car could only go between train stations, and the
train wouldn't carry anything larger than the car could...

I.e. What types of things were different from what you wanted -- NOT 
from what
they added on top of what you wanted.  I.e. you mention TLS and 
inter-computer
authentication...if those functions were compiled out, how would their 
product
differ from yours -- would they most be things that could be turned off 
because you didn't need them?  Or another way to phrase it -- is there 
stuff mostly
a superset of what you needed (or vice-versa).  If one was a strict
superset/subset of the other, obviously that makes things easiest.

But, what areas do you think they have incompatible changes where it isn't
just a matter of deleting / compiling out code in their stuff or is that 
something that you had time to investigate (maybe not if you were deep into
devel in dbus)...

I was even thinking of a design where a deamon listened on everything on
a dbus in one computer, and look for msgs that would (or should) be destined
for the other computer and transparently send them.  On the other end, the
same type of daemon would exist.

It seems that this might be similar in network parlance to a bridge -- 
something
that can unify two networks to look like 1 network segment.

That *might* be easiest for simple cases, though it might not extend to
larger collections -- but that might not be important.  You might want to
keep # of computers on an isolated network low to contain any problems.

Perhaps, conceptually, it's a more primitive version of MS's network access
protection agent, that ensures that foreign devices have the SW, HW, and 
settings to enforce desired policies, but *that* is getting way beyond 
the needs
of a dbus (I'd think) as well as simply configured computers that only 
talk to
their counterparts on a restricted+closed internet.






More information about the dbus mailing list