thx for the feedback. this is quite helpful. > This is a good question, but to me it seems separate from Netty integration.
agreed, thus my soliciting reviews before going after the responder delegation. we are interested in raw sockets and as such prefer the responder delegation and i will continue that work. till then (and i really don't expect it will take that long to implement) it would be trivial to implement a (likely short-term) hardwiring of the responder delegate with the requisite "setResponder(fooResponder)." hth, - james On Mon, Jun 28, 2010 at 8:50 AM, Doug Cutting <[email protected]> wrote: > On 06/25/2010 11:21 PM, James Todd wrote: > >> for your approach, what is the reconciliation process for when the >> user-provided-responder differs from that as specified in the >> request header? and again the question, why require the user to specify a >> responder when the request handshake includes all >> the necessary data to make such a decision? perhaps this is a detail but >> to >> me it is a key design consideration. >> >> i do believe the proper solution is to internalize the responder delegate >> based on inspection of the request handshake. >> > > This is a good question, but to me it seems separate from Netty > integration. > > With HTTP one can run many Avro services on a single port by hosting > different services at different URLs. With a raw socket-based approach one > could use a port per protocol. But that can be awkward, since it requires > more configuration and potentially more holes in firewalls. > > Dispatching on the protocol name in the handshake to different responders > might thus be a useful feature. But, again, this can be implemented > separately from permitting folks to use a Netty-based transport. A Server, > rather than containing a single Responder, might contain a ResponderSet or > somesuch. > > Doug >
