You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Julian Reschke <ju...@gmx.de> on 2021/02/09 17:41:05 UTC
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Am 26.05.2020 um 14:48 schrieb Julian Reschke:
> Hi there,
>
> you may or may not be aware that the HTTPbis WG has been working on a
> common structured syntax for new HTTP header (and trailer) fields.
>
> See
> <https://greenbytes.de/tech/webdav/draft-ietf-httpbis-header-structure-latest.html>
>
> and
> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/>.
>
> This is likely to be approved by the IESG soon, which means the RFC will
> be out in a few months.
>
> I'm working on a Java (8) implementation, see
> <https://github.com/reschke/structured-fields>. My intent is to
> contribute this to the HttpComponents project once this is stable and
> polished (and the RFC is out).
>
> This is more or less complete, and could use feedback.
>
> Best regards, Julian
So it took a bit longer, but the spec is now published as RFC 8941. I
updated the docs accordingly.
Feedback appreciated.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2021-03-16 at 17:19 +0100, Julian Reschke wrote:
> Am 16.03.2021 um 16:53 schrieb Oleg Kalnichevski:
> > ...
> > > So the question is how much of the actual parser (please have a
> > > look
> > > at
> > > <
> > > https://github.com/reschke/structured-fields/blob/master/src/main/java/org/greenbytes/http/sfv/Parser.java>
> > > ;)
> > > can benefit of re-using Tokenizer.
> > >
> >
> > All of it. The code in Tokenizer has been around for over a decade
> > and
> > is also being used by Apache Mime4j. It is reasonably simple and
> > flexible with reasonable performance characteristics.
>
> "All of it" seems... far fetched. Please have a lopk at the code;
> large
> parts are concerned with things that have nothing to do whatsoever
> with
> what Tokenizer does (such as parsing numbers, building lists etc).
>
Oh, well. We can agree to disagree like so many times before. I do
think all of your code would benefit from re-using existing parsing and
formatting primitives used by the rest of the library.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Julian Reschke <ju...@gmx.de>.
Am 16.03.2021 um 16:53 schrieb Oleg Kalnichevski:
> ...
>> So the question is how much of the actual parser (please have a look
>> at
>> <
>> https://github.com/reschke/structured-fields/blob/master/src/main/java/org/greenbytes/http/sfv/Parser.java>
>> ;)
>> can benefit of re-using Tokenizer.
>>
>
> All of it. The code in Tokenizer has been around for over a decade and
> is also being used by Apache Mime4j. It is reasonably simple and
> flexible with reasonable performance characteristics.
"All of it" seems... far fetched. Please have a lopk at the code; large
parts are concerned with things that have nothing to do whatsoever with
what Tokenizer does (such as parsing numbers, building lists etc).
> ...
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2021-03-16 at 15:11 +0100, Julian Reschke wrote:
> Am 16.03.2021 um 14:40 schrieb Gary Gregory:
> > I agree with Oleg, please consider contributing as joining a
> > community, not
> > just providing source code.
> >
> > Otherwise, a code dump can just happen anywhere.
> >
> > Gary
>
> I understand that sentiment (I wouldn't want a big, unmaintained code
> drop in Apache Jackrabbit either :-).
>
> Looking at the code shows that it's currently ~2K of lines, of which
> 900
> are in the actual Parser. The remainder implements the "object model"
> for structured fields plus serialization.
>
> So the question is how much of the actual parser (please have a look
> at
> <
> https://github.com/reschke/structured-fields/blob/master/src/main/java/org/greenbytes/http/sfv/Parser.java>
> ;)
> can benefit of re-using Tokenizer.
>
All of it. The code in Tokenizer has been around for over a decade and
is also being used by Apache Mime4j. It is reasonably simple and
flexible with reasonable performance characteristics.
I understand you are reluctant to rewrite your code but I would prefer
bits of your parser getting folded into the existing message parsers
and formatters instead of being completely detached from the rest of
the code base. That would not only help your code find a home but would
also benefit the project itself. Otherwise you might really be better
off hosting it on GitHub and referencing it as a companion project on
HC web site
http://hc.apache.org/httpcomponents-client-5.0.x/related-projects.html
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Julian Reschke <ju...@gmx.de>.
Am 16.03.2021 um 14:40 schrieb Gary Gregory:
> I agree with Oleg, please consider contributing as joining a community, not
> just providing source code.
>
> Otherwise, a code dump can just happen anywhere.
>
> Gary
I understand that sentiment (I wouldn't want a big, unmaintained code
drop in Apache Jackrabbit either :-).
Looking at the code shows that it's currently ~2K of lines, of which 900
are in the actual Parser. The remainder implements the "object model"
for structured fields plus serialization.
So the question is how much of the actual parser (please have a look at
<https://github.com/reschke/structured-fields/blob/master/src/main/java/org/greenbytes/http/sfv/Parser.java>)
can benefit of re-using Tokenizer.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP (draft-ietf-httpbis-header-structure)
Posted by Gary Gregory <ga...@gmail.com>.
I agree with Oleg, please consider contributing as joining a community, not
just providing source code.
Otherwise, a code dump can just happen anywhere.
Gary
On Tue, Mar 16, 2021, 09:24 Oleg Kalnichevski <ol...@apache.org> wrote:
> On Tue, 2021-03-16 at 13:28 +0100, Julian Reschke wrote:
> > Am 15.03.2021 um 19:50 schrieb Oleg Kalnichevski:
> > > ...
> > > Hi Julian
> > >
> > > Pretty much all message parsing routines in core [1] and client are
> > > based on Tokenizer [2]. Those parsers are forward-only and produce
> > > near
> > > zero (or fairly little) intermediate garbage.
> > >
> > > Id would be nice if parsing code in Structured Field Values re-used
> > > some of the message element parsers or were based on the Tokenizer
> > > if
> > > possible.
> > >
> > > Oleg
> > > ...
> >
> > Re-using existing message element parsers would not work; structured
> > fields is a new format and requires draconic error handling.
> >
> > Also, the parser internally is based on java.nio.CharBuffer, using it
> > in
> > a forward-only way (if I understand the term correctly), and only
> > allocates objects in order to build the resulting object model (which
> > can be quite complex in structured-fields).
> >
> > It's probably *possible* to rewrite all of this in order to re-use
> > some
> > existing code, but then it's somewhat unclear how this would make it
> > in
> > any way better.
> >
> > Best regards, Julian
> >
>
> It may not necessarily make it any better, but it would most certainly
> make new code more consistent with the rest of the code base, so that
> poor suckers like myself who maintain the library on a day by day basis
> might have a bit easier life maintaining your contribution.
>
> This also makes it somewhat unclear why one would want to contribute
> new code without making an effort of fitting it into the existing code
> base.
>
> This is a not a deal breaker, just a request for your consideration.
>
> We have a history of various people dropping a large chunks of code on
> us and walking away, leaving us with a thankless task of maintaining
> their original code for years to come. So far, if the past history is
> of any indication, all those contributions inevitably started to rot
> unless they fit well with the rest of the code base.
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2021-03-16 at 13:28 +0100, Julian Reschke wrote:
> Am 15.03.2021 um 19:50 schrieb Oleg Kalnichevski:
> > ...
> > Hi Julian
> >
> > Pretty much all message parsing routines in core [1] and client are
> > based on Tokenizer [2]. Those parsers are forward-only and produce
> > near
> > zero (or fairly little) intermediate garbage.
> >
> > Id would be nice if parsing code in Structured Field Values re-used
> > some of the message element parsers or were based on the Tokenizer
> > if
> > possible.
> >
> > Oleg
> > ...
>
> Re-using existing message element parsers would not work; structured
> fields is a new format and requires draconic error handling.
>
> Also, the parser internally is based on java.nio.CharBuffer, using it
> in
> a forward-only way (if I understand the term correctly), and only
> allocates objects in order to build the resulting object model (which
> can be quite complex in structured-fields).
>
> It's probably *possible* to rewrite all of this in order to re-use
> some
> existing code, but then it's somewhat unclear how this would make it
> in
> any way better.
>
> Best regards, Julian
>
It may not necessarily make it any better, but it would most certainly
make new code more consistent with the rest of the code base, so that
poor suckers like myself who maintain the library on a day by day basis
might have a bit easier life maintaining your contribution.
This also makes it somewhat unclear why one would want to contribute
new code without making an effort of fitting it into the existing code
base.
This is a not a deal breaker, just a request for your consideration.
We have a history of various people dropping a large chunks of code on
us and walking away, leaving us with a thankless task of maintaining
their original code for years to come. So far, if the past history is
of any indication, all those contributions inevitably started to rot
unless they fit well with the rest of the code base.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Julian Reschke <ju...@gmx.de>.
Am 15.03.2021 um 19:50 schrieb Oleg Kalnichevski:
> ...
> Hi Julian
>
> Pretty much all message parsing routines in core [1] and client are
> based on Tokenizer [2]. Those parsers are forward-only and produce near
> zero (or fairly little) intermediate garbage.
>
> Id would be nice if parsing code in Structured Field Values re-used
> some of the message element parsers or were based on the Tokenizer if
> possible.
>
> Oleg
> ...
Re-using existing message element parsers would not work; structured
fields is a new format and requires draconic error handling.
Also, the parser internally is based on java.nio.CharBuffer, using it in
a forward-only way (if I understand the term correctly), and only
allocates objects in order to build the resulting object model (which
can be quite complex in structured-fields).
It's probably *possible* to rewrite all of this in order to re-use some
existing code, but then it's somewhat unclear how this would make it in
any way better.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2021-03-15 at 10:40 +0100, Julian Reschke wrote:
> Am 09.02.2021 um 19:28 schrieb Oleg Kalnichevski:
> > ...
> > Hi Julian
> >
> > I will try to get around to taking a look. Anyway whenever you are
> > ready just raise a PR.
> >
> > Cheers
> >
> > Oleg
> > ...
>
> I'd prefer to get it first into the right shape in-place - before
> attempting a PR.
>
> You said earlier:
>
> > ... I would also ask you to make your code a bit more
> > consistent with the rest of the code base once you have a PR ready.
>
> Could you be a bit more specific what you're looking for?
>
Hi Julian
Pretty much all message parsing routines in core [1] and client are
based on Tokenizer [2]. Those parsers are forward-only and produce near
zero (or fairly little) intermediate garbage.
Id would be nice if parsing code in Structured Field Values re-used
some of the message element parsers or were based on the Tokenizer if
possible.
Oleg
[1] https://github.com/apache/httpcomponents-core/tree/master/httpcore5/src/main/java/org/apache/hc/core5/http/message
[2] https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/main/java/org/apache/hc/core5/util/Tokenizer.java
> Best regards, Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Julian Reschke <ju...@gmx.de>.
Am 09.02.2021 um 19:28 schrieb Oleg Kalnichevski:
> ...
> Hi Julian
>
> I will try to get around to taking a look. Anyway whenever you are
> ready just raise a PR.
>
> Cheers
>
> Oleg
> ...
I'd prefer to get it first into the right shape in-place - before
attempting a PR.
You said earlier:
> ... I would also ask you to make your code a bit more
> consistent with the rest of the code base once you have a PR ready.
Could you be a bit more specific what you're looking for?
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Structured Field Values for HTTP
(draft-ietf-httpbis-header-structure)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2021-02-09 at 18:41 +0100, Julian Reschke wrote:
> Am 26.05.2020 um 14:48 schrieb Julian Reschke:
> > Hi there,
> >
> > you may or may not be aware that the HTTPbis WG has been working on
> > a
> > common structured syntax for new HTTP header (and trailer) fields.
> >
> > See
> > <
> > https://greenbytes.de/tech/webdav/draft-ietf-httpbis-header-structure-latest.html
> > >
> >
> > and
> > <
> > https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/>
> > ;.
> >
> > This is likely to be approved by the IESG soon, which means the RFC
> > will
> > be out in a few months.
> >
> > I'm working on a Java (8) implementation, see
> > <https://github.com/reschke/structured-fields>;. My intent is to
> > contribute this to the HttpComponents project once this is stable
> > and
> > polished (and the RFC is out).
> >
> > This is more or less complete, and could use feedback.
> >
> > Best regards, Julian
>
> So it took a bit longer, but the spec is now published as RFC 8941. I
> updated the docs accordingly.
>
> Feedback appreciated.
>
> Best regards, Julian
>
Hi Julian
I will try to get around to taking a look. Anyway whenever you are
ready just raise a PR.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org