> On May 8, 2017, at 10:38 AM, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
>
> The prefreneces I have seen so far and adding my own:
>
> Mark : Ba, Bb, Ab, Aa, C
> Greg : Ba, Bb, C, Ab, Aa
In the latter email, Greg is ok with Ab, too.
> Ed : Ab
>
>
> So two main issues
>
> 1. (B,C) App sets one header at a time, allowing multiple values.
> OR
> (A) sets all headers at once (A) not allowing multiple values.
>
>
> 2. (a) App sets Trailer header
> OR
> (b) or container sets Trailer header (b).
>
>
> For 1. I prefer B, because we should allow multiple values for a header (similar setHeader and addHeader).
In our previous discussion, Bb) is
void setTrailer(String name, Supplier<String>)
If we invoke the setTrailer with the same name twice, the latter supplier is used.
This is more similar to #setHeader. This is not analogue to #addHeader in this case.
Given the above info, do you still vote for Bb)?
Thanks.
Shing Wai Chan
>
> For 2. I pefer b, but, like Ed, not if we use the same method for two functions. If we are stuck with one method I prefer a.
>
> So this would leave me as Bb
>
> If we can agree on these two points hopefully the rest will fall out.
>
>
> Thanks,
> Martin.
>
>
>
>
>
>
>
>
>
> From: Greg Wilkins <gregw_at_webtide.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 05/07/2017 08:18 AM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: Trailer header implementation
>
>
>
> Ed,
>
> I can definitely live with Ab and that is how Jetty has had it implemented currently.
>
> regards
>
>
> On 5 May 2017 11:37 pm, "Edward Burns" <edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com>> wrote:
> Points to emphasize relative to Shing-wai's Section 2.
>
> 1. Not preventing developers from doing less than 100% transport
> protocol compliant things.
>
> We've never been in the business of preventing apps from doing things
> that are not 100% protocol compliant. Especially with an area like
> trailers, it's important to allow for interoperability with endpoints
> that may or may not fully implement the underlying transport protocol
> "correctly" with respect to the RFCs.
>
> 2. Avoiding creating single methods that do multiple things.
>
> Both Ba and Bb feature a setTrailer method that does two things:
>
> 1. Appends a value to the
>
> Trailers:
>
> header.
>
> 2. Appends a name/value pair to the trailer fields.
>
> We've always avoiding introducing such complex and automatic APIs.
>
> Considering both of these points, I strongly favor option Ab.
>
> Also, we really need to close discussion on this because we're getting
> very near the end. If we can't come to consensus by start of business
> PDT next Friday, we should pull this feature from 4.0.
>
> Thanks,
>
> Ed
> --
> | edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com>| office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
>
>
>