[FoRK] spdy

Stephen D. Williams sdw at lig.net
Thu Nov 12 15:47:04 PST 2009

Lucas Gonze wrote:
> 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.
Does SSL necessarily break caching in the browser?  In their method, 
just because the transport is SSL/TLS doesn't mean that requests over it 
are logically HTTPS.  Or do you mean that it is an issue with caching 
proxies, transparent or not?  In the latter case, you Could (but 
shouldn't) use the fake CA certificate trick to get a (safe?) 
transparent man-in-the-middle.  This is how corporate environments that 
absolutely insist on seeing all traffic deal with HTTPS.

I think that the browser should be integrated into solving this problem, 
however another solution would be to have a local proxy that does a lot 
of this and presents a standard interface locally to the web browser.  
The other thing that they should benchmark against is using a web proxy 
or even SOX or an SSL VPN.  Those all use a single TCP connection over 
what could be a slow link.  The methods other than a true VPN should cut 
down on TCP slow start based waits.

Back to their methods, on the server side, the server could learn based 
on client patterns what other requests tend to go together, for images, 
CSS, etc. and preemptively provide that data at just the right point.

> 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
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork

More information about the FoRK mailing list