~sircmpwn/public-inbox

1

Have you considered XDR before BARE?

Tomer Weller
Details
Message ID
<CAObPTe+CjfkqC1TG=8c6cLimoyt7gEROuAQJ78P-xvKvmBJHsA@mail.gmail.com>
DKIM signature
pass
Download raw message
Hey there. big fan of your open source work - Thanks.

Was wondering if you considered XDR
(https://tools.ietf.org/html/rfc4506) and if so what were it's
disadvantages?

I understand that It's a bit less compact than BARE (aligns to 4
bytes, not 1) and it's age is showing (big-endian encodings,  ASCII
strings). With that said, it's a concise and minimal standard that has
been in production systems since the 80s. There are modern
implementations (here's one in go, for example:
https://github.com/xdrpp/goxdr) but rolling your own shouldn't be that
difficult. In fact, the set of supported types in BARE is *almost
identical* to XDR.

Would love to hear your thoughts. Maybe this time we can stay with
just 14 standards :)

P.S,
In full transparency: I work for the Stellar Development Foundation
where we use XDR extensively
(https://github.com/stellar/stellar-core/tree/master/src/xdr).
Details
Message ID
<C3S02EDO56ZC.LA9YYJ4GERPS@homura>
In-Reply-To
<CAObPTe+CjfkqC1TG=8c6cLimoyt7gEROuAQJ78P-xvKvmBJHsA@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
Hey Tomer, I gave a quick read over this RFC and it looks pretty neat!
It's the closest prior art to what I was aiming for. It still suffers
from some issues - you pointed out the 32-bit alignment as one, there
are others - so a revised spec based on this would have been necessary.
I think ultimately BARE is simpler and more compact, so its existence is
justified in the face of XDR. I might take some cues from XDR before I
finalize the BARE spec, though.

Cheers!
Reply to thread Export thread (mbox)