[FoRK] spdy

Lucas Gonze lucas.gonze at gmail.com
Thu Nov 12 15:10:35 PST 2009


I think that the value is in taking a conservative and responsible
approach to the radical task of making improvements to HTTP.

Within my limited understanding of their ideas, I believe they leave
the object model alone and keep their work within a safe zone.  The
one thing they are proposing that doesn't make sense at first look is
using SSL more extensively, since it breaks caching.

On Thu, Nov 12, 2009 at 1:55 PM, Stephen D. Williams <sdw at lig.net> wrote:
> Benjamin Black wrote:
>>
>> Lucas Gonze wrote:
>>
>>>
>>> http://dev.chromium.org/spdy/spdy-whitepaper
>>>
>>> This kind of proposal is usually wildly offbase, but this looks well
>>> conceived.
>>> It reminds me of first encountering HTTP-NG.
>>>
>>>
>>
>> In what has become Google SOP, they have neglected some obvious prior
>> art, intentionally or out of ignorance.  BEEP covered a lot of this
>> ground, whether it came to the right answers or not.
>>
>> http://beepcore.org/
>>
>
> I was thinking the same thing.  I always liked BEEP (originally BXXP), and
> have used it in projects.
> The other reinvention of the wheel is the AMQP work.
>
> Still, each new attempt pushes things forward.  I'm glad someone finally put
> the work into creating a working browser / web server combination.  I've
> been wanting this for a while.  Perhaps their code will be a convenient test
> bed.  In addition to the many-item-download problem, it would be great to
> have an automatic peer-to-peer download mechanism to make all web sites
> scalable.  It could be protected via Merkle trees and use bittorrent or
> better methods.
>
> Related concepts include W3C EXI "Efficient XML Interchange" (i.e. binary),
> Google Protocol Buffers, and GDATA.
>
> I agree with what is in EXI, however I have some additional ideas to avoid
> parsing, support deltas, and have sharable schema representations.
>  Additionally, I've specified the design of a binary superset of RDF for
> processing and size efficiency.  Back to that soon, as I'll need it shortly.
>
> Stephen
>>
>> b
>>
>>
>
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
>



More information about the FoRK mailing list