trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: git commit: TS-2268 Add support for opening protocol traffic sockets through the traffic_manager.
Date Fri, 18 Oct 2013 15:17:08 GMT
On Oct 18, 2013, at 6:08 AM, Uri Shachar <ushachar@hotmail.com> wrote:

> On Thu, 17 Oct 2013 15:49:19 -0700 James Peach wrote:
>> On Oct 17, 2013, at 3:23 PM, Uri Shachar <ushachar@hotmail.com> wrote:
>>> On Thu, 17 Oct 2013 11:45:41 -0700 James Peach wrote:
>>>> On Oct 13, 2013, at 2:15 PM, Uri Shachar <ushachar@hotmail.com> wrote:
>>>>> On Wed, 9 Oct 2013 10:41:42 -0700 James Peach wrote:
>>>>>> On Oct 8, 2013, at 1:19 PM, ushachar@apache.org wrote:
>>>>>> 
>>>>>>> Updated Branches:
>>>>>>> refs/heads/master 7ba121c9a -> 3c0c835c1
>>>>>>> 
>>>>>>> 
>>>>>>> TS-2268 Add support for opening protocol traffic sockets through
the
>>>>>>> traffic_manager.
>>>>>> 
>> There's some interesting features that you are talking about here. I'd like to bring
the discussion back to the specific API. Does this API help us get there? What can we do to
address the concerns that I raised about it?
> 
> I think we've reached an agreement on most of your concerns - the only item you raised
which is still somewhat open is allowing protocol plugins to sit after the SSL engine. I feel
that implementing this properly (with full support for plugin chaining, maybe even converting
the SSL engine into a protocol plugin) is beyond the scope of this change, and it is not required
to make the new API useful.
> (I'm all for it - just not in this context).
> 
> As discussed - I'm going to change TSPluginDescriptorAccept(cont) into TSNamedAccept(STRING,
cont) and add a "name" tag to the port descriptors so you'd configure 8085:plugin:name=myplugin:tr-full
in proxy.config.http.server_ports (I want to separate the name from the "plugin accept" functionality
to allow for future extensions).

API-wise that sounds fine. Perhaps TSNamedAccept is a uncomfortably close to TSNetAcceptNamedProtocol.
How about TSNetAcceptNamedDescriptor()?

Implementation-wise, is this still going to be implemented as a TransportType? I think that
it should be a separate property on HttpProxyPort so that you can accept on SSL and other
transport types.

J

Mime
View raw message