[newbie] accept()-ing process under supervision (was:Erlangish way of Iterator pattern)

Ulf Wiger (AL/EAB) ulf.wiger@REDACTED
Thu Jan 27 10:59:15 CET 2005

(Note: Joe wrote UBF. I don't speak for Joe. 
These are my thoughts.)

I think the state of UBF is that it needs some rethinking
in order to get further, but what is there is already
very good.

I have a ubf application that has been slightly 
modified to fit better into the OTP framework
(it's easier to configure, and uses supervisors etc.
as you would expect. It also contains a small program
that generates record definitions from a UBF spec
(for all types that look like tagged tuples.)

I've been using it with the 'builder' contrib (see Jungerl)

I've been meaning to put it up on SourceForge for 
a year or so, but never got around to it.

Example of a sys.config file where ubf_server is 


The compressed tar file is 116 KB, so I thought I'd refrain from 
posting it on the list. If anyone wants a (completely unsupported)
copy, please contact me.


> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of
> Bob.Smart@REDACTED
> Sent: den 27 januari 2005 00:31
> To: Joe Armstrong (AL/EAB)
> Cc: erlang-questions@REDACTED
> Subject: RE: [newbie] accept()-ing process under supervision
> (was:Erlangish way of Iterator pattern)
>  I was excited when I found UBF since it seemed to
>  be the right answer to client server. And Erlang is
>  ideal for servers and I can write the clients as
>  Java applets. As I wrote to a friend:
>    One of the things I like about UBF is that clients
>    to server is RPC, but the server can send extra
>    messages to the client. This is ideal. If you just
>    have an RPC system (like the web) then the client
>    only sees new info when it makes a call. If you have
>    a message based system then the clients can flood
>    the server. The ubf combination is fine. When a server
>    action might take a while the server can respond
>    immediately to the rpc, then send the answer later.
>  However I wonder what the state of it is. I just got
>  version 0.12 and the irc_server and Erlang irc-client
>  seem to work together ok (though error recovery is
>  not ideal). However the Java irc-client gives a
>  contract error.
>  There is also a report of an alternative Java
>  implementation. And indeed other languages would be
>  good: there is mention of a TCL version but I haven't
>  found it.
>  I'm sure I'll be able to use UBF even if these issues
>  aren't addressed. Congratulations on a great idea and
>  a useable implementation.
>  Bob

More information about the erlang-questions mailing list