UBF question

[Richard O'Keefe]

More precisely, UBF consists of THREE layers.
<quote src="">

   - UBF(a) is a "language neutral" data transport format, roughly
   equivalent to well-formed XML.
   - UBF(b) is a programming language for describing types in UBF(a) and
   protocols between clients and servers. This layer is typically called the
   "protocol contract". UBF(b) is roughly equivalent to Verified XML,
   XML-schemas, SOAP and WDSL.
   - UBF(c) is a meta-level protocol used between a UBF client and a UBF
   server.

</quote>


UBF(b) is analogous to an Interface Definition Language like Avro or
Protobufs OMG IDL.

It has one major extension, namely states.  The client and server are
modelled as finite state automata and messages may only be valid in certain
states, and responses indicate transitions to other states.  This is where
"contracts" are specified.  The only thing quite like it is in one of
Microsoft's extensions to C#, I think it was Sing# but it might have been
Midori.

UBF(c) is the layer where contract checking actually happens.

UBF(a) makes distinctions that JSON does not:  the distinction between
strings and binaries, the distinction between lists and tuples, and the
distinction between integers and floats (JSON does not guarantee that 10 is
an integer or that 10.0 is not an integer).  JSON can represent one thing
that UBF(a) could not, and that is maps with strings as keys, because UBF
was designed when Erlang did not have maps.  JSON is limited to string keys
only.  It would not take much to extend UBF(a) to maps.

The Smalltalk community have adopted an extension of JSON called STON, but
don't really have an analogue of UBF(b) or UBF(c).

On Sun, 7 Nov 2021 at 05:02, Ulf Wiger <ulf@REDACTED> wrote:

> UBF consists of two parts: UBF(a), which describes the daya types, and
> UBF(b), which describes the interaction part.
>
> https://ubf.github.io/ubf/ubf-user-guide.en.html#specifications
>
> BR,
> Ulf W
>
> Den lör 6 nov. 2021 16:14 <hamishberridge@REDACTED> skrev:
>
>> Does the role of contract checker act something like validator? If so,
>> does that imply binary_to_term/ term_to_binary does not use that because
>> the communication happens within Erlang environment? I could totally go
>> wrong as I am not familiar with it; but I am curious, because I learned a
>> lot of concepts from Erlang and from reading Joe Armstrong's thesis, even
>> though I never wrote any Erlang code at all. Really appreciate those
>> writings. That helps me a lot in learning system design, and many other
>> parts in programming as well.
>>
>> Oct 28, 2021, 21:51 by ulf@REDACTED:
>>
>>
>> The key feature of UBF was that beyond being a serialization format, it
>> was also a contract checker.
>> That was a very nice feature. If you'd like to do something like that
>> today, perhaps you'd go for JSON or MessagePack encoding, JSON-Schema and
>> Jesse.
>>
>> Needless to say, Joe's solution was far more elegant. It was also far
>> less supported, even when he was alive. Joe was always searching for the
>> next interesting challenge, and as memory serves, he parked UBF thinking
>> that he wasn't 100% satisfied with it. It didn't bother him to park
>> something for a decade while trying to address that final wrinkle.
>>
>> BR,
>> Ulf W
>>
>> [image: Vereign Seal]
>> <https://gmail.app.vereign.com/#CiAzy_GB8f6QvveZ4EbTaXoDdsWTb_ETB6W49Cwj1RyD1xIggbHUSgcbmAeIDsfNGcBv5GttvylTY3bzBmlLx8UQ6AA=>
>>
>> On Thu, Oct 28, 2021 at 7:45 AM <hamishberridge@REDACTED> wrote:
>>
>>
>> I haven't used Erlang, so I suppose my question is very naive. I read
>> that UBF[1] is not maintained. So I am wondering what's used by Erlang as
>> serialization format? Is there a new one that replaces UBF? Or UBF is still
>> used as it, it's just not much change as it's stable?
>>
>> If there are UBF alternative options, what options are available?
>>
>> Many thanks
>>
>> [1]. https://github.com/ubf/ubf
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20211108/eb09f997/attachment.htm>