Re: Lazy Blob

On Thu, Aug 2, 2012 at 11:09 AM, Florian Bösch <pyalot@gmail.com> wrote:

> On Thu, Aug 2, 2012 at 6:37 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>> I am not proposing a "particular browser supported semantic" for a
>> "specific implementation on the server". I have suggested, by way of
>> example, two particular patterns be supported independently of any such
>> implementation. I did not restrict the results to just those patterns in
>> case someone wishes to generalize. That is little different from the
>> proposed or implied XHR patterns being discussed.
>>
>
> So I'll take a stab, the remote blob resource/range protocol over WS 1.0:
>
> 1) A websocket to a URL is opened by the browser, the path and query of
> the URL is interpreted to specify a resource.
> 2) During the lifetime of a websocket session onto a wsblob resource, the
> resource is guaranteed to be reflected unchanged to the session, it cannot
> be changed, appended or removed.
> 3) The client has to send these bytes "<handshake>" as a first message
> 4) The server has to respond with a "<handshake><length>" message to
> indicate that he understands this protocol and indicate the byte length of
> the resource.
> 5) after successful setup the client may request ranges from the server by
> sending this message: "<range><start><end>", start and end have to be in
> range of the byte resource.
> 6) The server will respond to each range request in the form of
> "<range><start><end><bytes>" in case that a range request is valid, the
> length of <bytes> has to be start - end. In case a range is not valid the
> server will respond with "<invalid><start><end>.
>
> These are the protocol field definitions:
> handshake := "wsblob"
> length := unsigned int 4 bytes
> start := unsigned int 4 bytes
> end := unsigned int 4 bytes
> bytes := string of bytes
> range := 0x01
> invalid := 0x02
>

ok, that is fine, but I never suggested limiting the semantics of
interchange to a "resource/range protocol"; as is clear, the above
application specific protocol does in fact use the "multiple" pattern I
described, i.e., each interchange consists of a pair of send-response
messages, each of which can be encapsulated in a blob, and each response
blob could be implemented as a remotable 'promise' encapsulating a send
blob and its resultant response blob;