[erlang-questions] UBF(A) vs ETF / UBF(C) vs gen_fsm

[Joe Armstrong]

On Wed, Sep 22, 2010 at 11:28 AM, Edmond Begumisa
<ebegumisa@REDACTED> wrote:
> Hello all,
>
> I've been looking at Dr. Joe Armstrong's UBF with interest, especially for
> IPC between two Erlang nodes over TCP (non-epmd) and possibly between an
> Erlang node and a XULRunner client (JavaScript/XPCOM). I have two questions
> for those with UBF experience...

That sounds like a very good idea - I'd really like to see clear separation of
interest - Erlang on one side of a communication channel, XULRunner on
the other side
with a clear specified interface between and no feature leakage between the two.

You could try UBF for this - if it turned out that it wasn't good I
have a few other
tricks up my sleeve - how is the javascript/XULrunner side of things?
- the erlang bit
is easy - can you easily setup the underlying socket communication
with XULrunner?

>
> 1) Concerning UBF(A): Joe mentioned in his original paper that UBF(A)
> encoding was more upto 40% more compact than the VM External Term Format.
> But that was 8 years ago. I understand the external term format has improved
> since then. Is UBF(A) still more compact?

I haven't measured but I suspect UBF will be more compact - the UBF
caching optimization
allows you to substitute any repeated term by a single character - so
if you discover that
some term is repeated, you can just replace it by a single character -
this depends upon the
encoder, which is up to you.

>
> 2) Concerning UBF(C): If one is using gen_fsm server-side together with
> UBF(A) over the wire, would I be correct in saying that the OTP behaviour
> provides the contract checking that UBF(C) would provide? That is, would
> using gen_fsm with UBF encoding for messages render the UBF(C) contract
> checker redundant?

No - to do this you would have to compile a UBF(C) state machine to a
gen_fsm state machine
I see no advantage in this - it's essentially the same thing, but the
UBF state checker is
is more specialized than gen_fsm. gen_fsm is a generic machine. The
UBF(C) checker is
specialized for UBF contracts

Another thought - the UBF type system would *easily* map to a JSON
transport format
I blogged this in 2009

http://armstrongonsoftware.blogspot.com/2009/02/json-protocols-part-1.html

It's the same idea as UBF using JSON instead of UBF(A) - the encoding
isn't as pretty
but it makes interoperability easier - I guess *every* language has a
JSON encoder/decoder
so you don't have to write a UBF encoder/decoder.

Having parsed the JSON (or UBF(A) ) the parse trees would be
essentially the same thing
so the contract checker would be easy.

Cheers

/Joe

>
> - Edmond -
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>