On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams <glenn@skynav.com> wrote:
> So? Why should lazy blob be specific to HTTP specific semantics when an
> arbitrary URL is not specific to HTTP?
>
Reading a resource at arbitrary locations requires two things:
1) That a resource is understood as a container of bytes having a start and
end
2) That the protocol used to access it supports specifying a range into
that resource
The HTTP protocol satisfies these two criteria (disregarding things like
chunked transfer etc. for now):
1) a HTTP GET is understood as an access to a resource having a start and
end, the URL maps to the resource location or handler
2) HTTP ranges let you specify which part of that resource you'd like to get
The WebSoicket protocol does not satisfy those conditions
1) A resource is understood as a realtime duplex channel of communication
between two communication partners, the URL indicates which channel you're
using.
2) Websockets do not understand or handle HTTP content ranges, there is no
part of the websocket protocol that would dictate accessing a
byte-container at the other at specified offsets into a resource.
So if you want to have a lazy reader on Websockets you have either:
1) respecify the websocket protocol to include content semantics for
accessing resources defined by an URL and having a specified size OR
2) define an additional protocol on top of websockets, which websockets
know nothing about, that allows a custom implementation at the server side
to respond in a meaningful fashion to resource range requests.
Both these things are completely outside of the scope of "generalizing lazy
blobs".