4 Replies Latest reply on Jan 14, 2009 11:28 PM by trustin

    HTTP Tunnel subproject

    trustin

      Andy Taylor of JBM team will be working on the following issue:

      * https://jira.jboss.org/jira/browse/NETTY-109

      I believe we will also be able to benefit from this if implemented generic enough (that's the purpose.) Please feel free to jump in and leave comments to mention what's required on the JBREM side.

        • 1. Re: HTTP Tunnel subproject
          dmlloyd

          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

            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

              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

                 

                "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.