Hi Jim,
Sorry about the disconnect, I was out Monday and yesterday. I'll be sure to
attend the IRC chat tomorrow. In the meantime, some more quick comments.
----- Original Message -----
<snip/>
If I understand correctly, would a system service transport use a
low level
communication mechanism, like a socket for instance? This does not
seem like
an appropriate approach for a local scenario,
Right, for the local scenario, I was thinking the callback instance
would be put on the thread local context and the proxy would access
it from there as opposed to going out over a socket and back in
through a listener. Basically, it would be an optimization of the
remote case. I think we can further optimize things depending on
scopes, e.g. if the callback scope is "module", we could possibly
avoid threadlocal storage and have the proxy hold on to an instance
directly.
Pointing at the callback instance directly from the proxy would eliminate
invocation chains and the ability to add interceptors to them, wouldn't it?
Also, I'm not sure using a thread local in the core is a good idea if an
intention is to allow the core to be embeddable in, for instance, a managed
environment, as thread local does not necessarily mix well with thread
pools.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
