On Wed, Feb 22, 2012 at 8:57 AM, Mark Thomas <ma...@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 <ma...@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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
