On 12 April 2017 at 11:07, Greg Wilkins <gregw_at_webtide.com> wrote:
> All,
>
> I'm a bit agnostic on the matter of Map<String,String> vs
> Map<String,List<String>> as regardless we will have to check strings for
> CSV anyway.
>
> I'm a bit cautious about the setTrailerCallback(Consumer<Map<String,
> String>> callback) API because there are insufficient details about when
> and who will call callback.accept(trailers)). If it is a true
> container callback, then it needs to be treated like the other container
> callbacks - context classloader set, mutually excluded from other callbacks
> etc.
>
> Alternately, we could say that it will only ever be called by the thread
> that calls HttpInput.read() and is about the return -1, but immediately
> prior to that will call accept?
>
> Either way, I don't see much improvement on a method like
>
Sorry pushed send too soon.
Either way, I don't see much improvement on a method like:
/**
* @return A map of trailers or null if none are available.
* @throws IllegalStateException if called before all request input has
been consumed.
*/
public Map<String,String> getTrailers();
So my preference is A.c. If we are to go with A.e, then we need a lot
more specification about how and when it is to be called. Eg. can a call
to the setter immediately callback the accept within the scope of the call?
I'm also in favour of B.c, but again we need to be more specific about what
thread will call that API. Specifically I believe that we should say that
it is called within the scope of whatever thread/call causes the response
content to be completed. Typically this will be any thread calling close()
on the output stream or writer.
cheers
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com