tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: SPDY support
Date Wed, 22 Feb 2012 17:01:54 GMT
On Wed, Feb 22, 2012 at 8:57 AM, Mark Thomas <markt@apache.org> wrote:

> On 22/02/2012 16:51, Costin Manolache wrote:
> > First part submitted. For the second: what is the process for adding a
> > dependency ?
>
> Why do you need the dependency?
>

Spdy requires header compression - with a pre-defined dictionary (
containing header names and common values ). It also requires 'flush' - a
single compression context is used for all headers in the stream. AFAIK
this is not possible with the jdk compress library.

That's one of the ways spdy gets its speed - it is not optional in
chrome/firefox.

Costin


>
> > jzlib is BSD - I added it to 'download' and build.properties.
>
> LICENSE and NOTICE need updating as well (multiple locations). So will
> the pom files.
>
> > I can make it optional (i.e. skip building the code that depend on it if
> > jzlib is missing ), but it doesn't seem to be worth it.
> > Do automatic builders run 'ant download' ?
>
> They handle dependencies. Some additional configuration may be required.
>
> > Any concerns with it ?
>
> Depends on why it is required.
>
> Mark
>
>
> >
> > Costin
> >
> > On Thu, Feb 16, 2012 at 2:11 PM, Mark Thomas <markt@apache.org> wrote:
> >
> >> On 16/02/2012 01:44, Costin Manolache wrote:
> >>> That doesn't mean the application must receive the entire message as
> one
> >>> byte[]
> >>> or as a Stream.
> >>> You can have a very large fragment but still read it in smaller buffers
> >> and
> >>> notify
> >>> the user of message start and for each fragment ( I guess like xml
> >> parsing
> >>> ).
> >>
> >> I see where you are coming from now. A purely message based API would be
> >> possible in that case. The downside is increased complexity in the
> >> applications as they would have to maintain additional state across
> >> messages. I'm not completely against the approach, just not yet
> >> convinced that the trade is worth it. I'd prefer to have some hard
> >> evidence to work with but that is unlikely to be forthcoming until folks
> >> start using this API. With that in mind, I'm going to focus on the
> >> various contributions folks have made and move the implementation closer
> >> to something that is usable.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message