[newbie] accept()-ing process under supervision (was:Erlangish way of Iterator pattern)
Ulf Wiger (AL/EAB)
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
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
> 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.
More information about the erlang-questions