i think the fundamental question here is should the container bhee trying
to enforce/assist with compliance to the RFC - ie should the container
manage the relationship between the Trailers header and the trailers
themselves.
Ed's point of view is that we don't enforce/assist with RFC correctness on
many other fields and the API can be used to create many non-compliant
messages. If we agree with that point of view then the existing proposed
API (Ab) is the natural result.
If we don't agree with that point of view, then the container needs to help
somehow. Ba appears to be the winner there.
I'm sitting on the fence as to if I agree with Ed or not. But as time is
short, then I think Ed's point of view does have the appeal of simplicity
and inertia.
cheers
On 8 May 2017 at 19:38, 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
> 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).
>
> 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*
> <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* <edward.burns_at_oracle.com>| office: *+1 407
> 458 0017* <%2B1%20407%20458%200017>
>
>
>
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com