Access Controls

[linas@linas.org]

It's been rumoured that Derek Atkins said:
> 
> In my solution, we would define two RPC programs, the forward
> (client->server) program which would be all the client-originated
> requests and server responses, and the callback/event (server->client)
> program, which would be the event notification.  Then all we do is
> build the network connection, add any transport-level encryption we
> want, and then apply the forward service on the server side, and the
> callback service on the client side.  All data is multiplexed across
> the single TCP connection.  It's kinda neat! :)
> 
> > For rpc or xml/soap, which don't have events, I don't know how to 'roll
> > our own', it seems complicated. Firewalls mess things up. I've never
> 
> See above; I've solved this problem (at least for ONC-RPC ;) -- the
> client always initiates connections to the server (so you can get
> through a NAT or firewall), and callbacks come back on that (single)
> TCP transport.

I suggest posting the demo code somewhere when you have it shaken
out (including a thorough explanation of why this is an important
feature/'good thing').   Can you abstract the interfaces to something 
generic?
Is there some sort of rpc-special-interest-group, with a mailing
list or web page, that this would be a suitable submission for?