-
1. Re: HTTP Tunnel subproject
dmlloyd Jan 14, 2009 10:29 PM (in response to trustin)It looks like an interesting idea at least. But when it comes time to implement the HTTP transport for Remoting, I think the most important thing we can do is to define exactly how to best map request to the HTTP protocol, so that we can consistently implement the protocol between the various frameworks that we plan to support. Once we have done that, the choice of tool is going to come down to what works best to implement that mapping.
-
2. Re: HTTP Tunnel subproject
trustin Jan 14, 2009 10:51 PM (in response to trustin)Considering that XNIO transport will also be a part of Netty, I think the HTTP tunnel should work just fine with XNIO pipe and socket transport as well as Netty's built-in transports. (i.e. the HTTP client transport should be a meta-transport of other transports).
Please let me know if you have other frameworks in mind so that I can take account into. -
3. Re: HTTP Tunnel subproject
dmlloyd Jan 14, 2009 11:20 PM (in response to trustin)I see, so you're saying that it would be a generalized tunnel for any socket protocol? That could be useful for Remoting and for other things as well.
This does imply that we (again) need to discuss the direction to go with HTTP as a Remoting transport - should it be a separate mapping, or just be a tunnelling platform for socket-based protocols, or both, and why? -
4. Re: HTTP Tunnel subproject
trustin Jan 14, 2009 11:28 PM (in response to trustin)"david.lloyd@jboss.com" wrote:
I see, so you're saying that it would be a generalized tunnel for any socket protocol? That could be useful for Remoting and for other things as well.
Exactly. :-)"david.lloyd@jboss.com" wrote:
This does imply that we (again) need to discuss the direction to go with HTTP as a Remoting transport - should it be a separate mapping, or just be a tunnelling platform for socket-based protocols, or both, and why?
That's a good question I missed out. I think it depends on whether we need to interoperate with other HTTP client module. If we don't, tunnelling is the easiest way to get HTTP support for Remoting IMHO. If we want to allow others write an HTTP-based client implementation, then we do need a well defined separate mapping. My opinion is that users will not bother with writing an HTTP client by themselves.