Re: Should Web Services be served by a different HTTP n+1?

Hi,

I am just joining this discussion thread and I have a comment on what was
mentioned by William "precisely the following text - copied from William's
message below":

* I think we need to do a little more. I think we should define a "minimal
implementation" and have a way for client and server to signal this. A
minimal implementation would not be able to do any or some of these:
 - compression
 - server-initiated streams
 - stream priority
 - credentials
 - all but a small set of headers.
 - multiple concurrent streams
*

 Hassnaa: Is video streaming considered one of the services for which
HTTP2.0 could present a gain? or the focus right now is on web-browsing for
the minimal implementation.

Regards,
Hassnaa



On Thu, Jan 24, 2013 at 2:19 PM, Yoav Nir <ynir@checkpoint.com> wrote:

> It might end up smaller than what you need for an HTTP/1 client. But that
> also allows us to implement just one protocol on the server for both
> full-capability and minimal clients. Similarly for full-capabilities client
> working with minimal servers.
>
>  On Jan 25, 2013, at 12:08 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
>  So... why would someone who didn't want these things use HTTP/2 instead
> of HTTP/1?
>
> -=R
>
>
> On Thu, Jan 24, 2013 at 2:03 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>
>>
>> On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com> wrote:
>>
>> > On Thu, Jan 24, 2013 at 12:41 PM, William Chan (陈智昌)
>> > <willchan@chromium.org> wrote:
>> >>> The main one is that the receiver has to have enough memory to store
>> the
>> >>> dictionary.
>> >>
>> >> I think this boils down to the argument on the other thread. Do the
>> >> gains for keeping state outweigh the costs? Note that given Roberto's
>> >> delta compression proposal, the sender can disable compression
>> >> entirely, so the receiver does not need to maintain state. Browsers
>> >> probably would not do this, due to our desire to optimize for web
>> >> browsing speed. For web services where you control the client, you
>> >> indeed would be able to disable compression.
>> >
>> > IMO we need stateful compression to be absolutely optional to
>> > implement.  (If we choose to go with stateful compression in the first
>> > place.  I think we shouldn't.)
>>
>> I think we need to do a little more. I think we should define a "minimal
>> implementation" and have a way for client and server to signal this. A
>> minimal implementation would not be able to do any or some of these:
>>  - compression
>>  - server-initiated streams
>>  - stream priority
>>  - credentials
>>  - all but a small set of headers.
>>  - multiple concurrent streams
>>
>> Maybe we need a CAPABILITIES control frame that will allow client or
>> server to communicate to the other what capabilities they don't have.
>>
>> A truly minimal client would be capable of one stream at a time - really
>> down to HTTP/1.0 functionality with the new syntax.
>>
>> Would this allow Phillip to use HTTP/2 for minimalist web services?
>>
>> Yoav
>>
>>
>
>
> Email secured by Check Point
>
>
>