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

[L A Walsh]

Thiago Macieira wrote:
>
> It's missing some functionality that was never written. It also predates the 
> ability to pass file descriptors, so the two functions to get and set the 
> bytes miss extensions to get and set the file descriptor list from the 
> DBusMessage. If you're interested, you can contribute those extensions.
>   
----
    Well, my personal interest is just having it work over a "local"
(the network is the computer) network w/1person/subnet -- with the
auth/and such using pre-existing components like a one-time login that
logs you into server, because, in my case, server is a Samba-DC (older type)
but that validates me and provides sid<->uid translations for system
services.
>   
>>> That's called AllJoyn. It has been done and is about a decade old.
>>>       
>> ---
>>     If that's the case, why is effort being spent on DBUS?  To what
>>     
>
> 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).
>  D-Bus continues to mean to be a local-system bus, for intra-system
> inter-process communication. 
>   
===
    Falling back to definition -- what about co-processing systems where
they are, together, considered 1 system.  The network is meant to be
viewed as another type of bus.  Of course 10Gb for a bus is slow in
this day and age, but 20 years back and it might have been considered
fast.  Since no authorization, encryption or integrity features are needed,
only using some efficient low-level proto is needed to tie those together.

    The rub can come if the other product is "closed" proprietary, which
I'm getting, it was.

Similarly, system addressability could be as simple of dbus sending
messages to 1 display or the other (even if 1 really had no display).


> AllJoyn meant to be a smarthome inter-system communication mechanism, with 
> support for encryption, authentication and authorisation, plus sleepy nodes.
>   
that's nice...how far away from product were they?


> AllJoyn did that. They never came to this mailing list to talk about their 
> objectives and changes, they never asked about keeping wire compatibility. 
---
They considered you not worth the bother/effort, I'd guess...typical.
> PS: note my use of the past tense for AllJoyn.
---
    I take it they never made any code-dumps anywhere that might allow
re-use?  Sigh...So typical.

---
    Fortunately, at least some of those with secure networks aren't really
demanding all the wizz-bangs that would be needed in a hostile environment.
Not speaking for others, I'd just need things not deleted/forced off nor
advertised as insecure -- because it would motivate others to remove
network code (why would that insecure stuff be needed)?

    While a default-config might only show secure setup -- README docs
might detail what could be done / how it could be done -- for
expansion onto a secure network.  Hopefully small example in another
note...this one is long enough.  :-)

-l