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

[Thiago Macieira]

On Sunday, 15 July 2018 11:44:20 PDT L A Walsh wrote:
>     Although...it is always good practice and a sign of good SW design to
> to leave hooks for later parameterization, where one sees the opportunity.
> Though most such hooks cannot be seen in advance, sufficiently
> modular code can be more easily split apart to allow for such.

Correct. In fact, we have almost that. See:

> > If you want that, I recommend using the "D-Tube" functionality inside
> > libdbus-1 that allows you to get a DBusMessage from a byte stream and also
> > write a byte stream from a DBusMessage. How you transmit and receive those
> > bytes is then up to you. But even that functionality is limited, as we've
> > never written the code to initialise a DBusConnection (much less a bus
> > connection) without the handshake protocol, for which there is no "D-Tube"

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.

> > 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. D-Bus continues to mean 
to be a local-system bus, for intra-system inter-process communication. 
AllJoyn meant to be a smarthome inter-system communication mechanism, with 
support for encryption, authentication and authorisation, plus sleepy nodes.

> goal that AllJoyn wouldn't support?  Personally, I try to grab working
> code from other places to start with -- and either use it directly, or
> try to make it compatible to make it easily extensible by others.  Not
> always possible, but those who reinvent the wheel and make it incompatible
> with the original would seem to be wasting their talent.  I.e. if

AllJoyn did that. They never came to this mailing list to talk about their 
objectives and changes, they never asked about keeping wire compatibility. I 
wouldn't even know about them, except for the fact that the company I work for 
ended up having a business discussion with the company that produced AllJoyn, 
when we were exploring Smart Home.

> smart enough to invent some replacement, think about how the concept(s)
> could be advanced if they could work on new stuff on building on the old
> instead of reinventing the old.

PS: note my use of the past tense for AllJoyn.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center