On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams <gl...@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".
