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

[Edmond Begumisa]

Thanks very much for your quick response...

On Wed, 22 Sep 2010 20:29:30 +1000, Joe Armstrong <erlang@REDACTED> wrote:

> 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.

I've had some unpleasant experiences with informal home-grown/private  
protocols so the benefits of UBF for my purposes immediately jumped out at  
me. It's one of those things you can't appreciate unless you've been there.

> 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?

Promising but it's still early stages. One problem so far is that  
XULRunner is best suited for HTTP communication (raw TCP sockets are  
doable but a real pain). I'm currently trying to see if rather than going  
against the grain by wresting with Mozilla's lower level socket API's, it  
might be easier to have the Erlang side serve UBF over HTTP using say  
mochiweb (long-poll/keep-alive issues notwithstanding.) I'll be sure to  
post some code when I've got something working.

I'm intrigued by those tricks you mention?!?!

> 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.

Perhaps it's time for a UBF EEP! IMO, it would also make writing &  
debugging port drivers easier.

> 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

I see... I understand now.

> 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.

Ditto! It's actually that blog entry that got me to look at UBF (what ever  
happened to part II of that BTW!?!) I've been contemplating using Gemini's  
UBF-JSON to make life easier on the XULRunner side. I don't know if you've  
had a look at/recommend their implementation...

http://github.com/norton/ubf-jsonrpc

Erlang and XULRunner could be a lethal combination. I'm sure I'm not the  
only one who has seen this.

Thanks.

- Edmond -

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/