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:
>>> This kind of proposal is usually wildly offbase, but this looks well
>>> 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.
> 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.
> FoRK mailing list
More information about the FoRK