[
https://issues.apache.org/jira/browse/TS-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122230#comment-13122230
]
Alan M. Carroll commented on TS-961:
------------------------------------
I don't like just appending the transparency argument. That kind of thing got
us in to trouble in the internals until we switched to the NetVCOptions struct.
I think we should start off on the right foot here, even if it's just one
option for now. The general rule should be that where we expect more than one
default argument, all the default arguments should be put in a struct and
nothing in the struct can be required for the call to work. That is, for any
value in the struct either it is not needed or a reasonable functional default
is available to the implementation.
While it seems reasonable to me to have two flavors of the call, one without an
option struct and one with, we don't want to version this every time a new
option is added. But how can the implementation detect which version of the
struct was passed? A common technique is to have a version or size member at
the front which has this information, but that might be too ugly for us.
Another completely different alternative is to do the socket thing and have
separate "open" and "accept" calls with the ability to set options via other
calls between the two. Then additional options can be added without breaking
any existing API.
> Extend TS API to support TSNetAccept with inbound transparency
> --------------------------------------------------------------
>
> Key: TS-961
> URL: https://issues.apache.org/jira/browse/TS-961
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
> Reporter: Yossi Gottlieb
> Assignee: Alan M. Carroll
> Priority: Minor
> Fix For: 3.1.1
>
> Attachments: api_transparency.diff
>
>
> This is required for protocol plugins to use this capability.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
