Extending Functionality: gen_server_ext

[Chris Pressey]

On Wed, 19 Mar 2003 20:36:38 +0100
"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> wrote:

> > But surely the client isn't expecting the call to be transformed into
> > a cast... ??  My vague feeling is that ideally there should be one
> > function, gen_server_ext:next(), that goes to the same type of handler
> > (cast, call, info etc) in the next behaver.
> 
> Oh, sorry -- I didn't read your question properly. Long day, lots of
> work:-) Of course my answer only applies to calling next_call from a
> handle call.

No problem.  It probably wouldn't be a common typo, and I'm sure there'd
be a way to catch it before anything weird happens... by examining the
call stack, perhaps :)

> > Another question: what are the pros and cons of having to call
> > next_call() et al, as opposed to returning a value like {next_call,
> > ...} from the handler, and having gen_server_ext pay attention to
> > that?
> 
> If you return with {next_call, ...} then you can't get the answer back
> and refine it. It's something in between the two options you mentioned
> before, I think.

Yeah, makes sense.

> I have this feeling that there's a lot more to dig out here.
> 
> regards,
> Vlad

I dunno, it sounds better and better the more I think about it.

Consider an example, say you have a server and you want to add logging of
some kind.  All you need to do is add another behaver inside
gen_server_ext, "in front of" your server, that logs whatever, then calls
next_call.  Seems more elegant to me than having a seperate gen_server for
logging which delegates to the original gen_server.

But that's kind of a contrived example, I'll try to think of a better one.

On the subject of what I've been exploring - that is, having a seamless
transition between processless and processful objects - I had a bit of an
epiphany this afternoon - I think it would turn out to be something like
Ulf's mdisp package (which I unfortunately haven't looked at closely
enough yet), except more dynamic.  I have something half-coded that I'll
try to finish - basically, I have a bunch of things in an ETS table, and a
function notify/2 which sends a thing a message.  If the thing is inactive
(no process,) it gets activated first (a process is spawned for it.)  The
process generally runs a receive statement (which can deactivate itself
after a timeout, if need be.)  This should let me track tens (or maybe
hundreds) of thousands of things, but only have as many processes as are
actually needful at any given time.

I'll keep y'all updated... :)

-Chris