Protocol Specifics: Streaming Binaries
Jared "Lucky" Kuolt
responses, however it does not indicate how that binary is handled.
For the server-side, is it expected to be appended to the function
arguments? For example (in Python):
def resize_photo(height, width, binary): ...
Where the height and width args are sent in the request packet, and
the binary is sent via SB?
-> {info, stream, []}
-> {call, mod, resize_photo, [Height, Width]}
... binary data ...
Another question regards the reply to such a request. The spec says
that a reply is sent with the length of the binary:
<- {reply, 247817}
But what about the actual reply from the function call/cast? Is it
expected to double up like this?
<- {reply, 247817}
<- {reply, Response}
This is ambiguous and I don't like it. I'd much rather see the SBR
length in an info packet like this:
<- {info, stream_request, [{length, 247817}]}
<- {reply, Response}
Thanks for reading.
--
Jared "Lucky" Kuolt
Tom Preston-Werner
<luckythetour...@gmail.com> wrote:
> The BERT-RPC specification defines Streaming Binary requests and
> responses, however it does not indicate how that binary is handled.
> For the server-side, is it expected to be appended to the function
> arguments? For example (in Python):
>
> def resize_photo(height, width, binary): ...
>
The spec does not define how your application or framework handles the
incoming stream. You could read the entire stream into memory and pass
it to a function like this, but that's probably unwise. A better
approach might be to have the framework register a callback that will
be sent the incoming data in chunks as they are received. Really, it's
up to you!
> Another question regards the reply to such a request. The spec says
> that a reply is sent with the length of the binary:
>
> <- {reply, 247817}
>
The spec actually just uses that as an example return value; you are
not required to send back the stream size as a response. If your
application needs additional verification of the final stream size the
you might have it return that value, but the protocol is designed so
that that is unnecessary.
Hope this helps!
Tom
--
Tom Preston-Werner
GitHub Cofounder
http://tom.preston-werner.com
github.com/mojombo
Jared "Lucky" Kuolt
> On Apr 6, 12:35 pm, "Jared \"Lucky\" Kuolt"
> <luckythetour...@gmail.com> wrote:
>> The BERT-RPC specification defines Streaming Binary requests and
>> responses, however it does not indicate how that binary is handled.
>> For the server-side, is it expected to be appended to the function
>> arguments? For example (in Python):
>>
>> def resize_photo(height, width, binary): ...
>>
>
> The spec does not define how your application or framework handles the
> incoming stream. You could read the entire stream into memory and pass
> it to a function like this, but that's probably unwise. A better
> approach might be to have the framework register a callback that will
> be sent the incoming data in chunks as they are received. Really, it's
> up to you!
That's about what I figured, but didn't want to step on any toes. My
thought is similar to yours where a binary is external to the args as
a stream (probably cStringIO or similar).
>
>> Another question regards the reply to such a request. The spec says
>> that a reply is sent with the length of the binary:
>>
>> <- {reply, 247817}
>>
>
> The spec actually just uses that as an example return value; you are
> not required to send back the stream size as a response. If your
> application needs additional verification of the final stream size the
> you might have it return that value, but the protocol is designed so
> that that is unnecessary.
I read the spec wrong! Thanks for the clarifications!
>
> Hope this helps!
>
> Tom
>
> --
> Tom Preston-Werner
> GitHub Cofounder
> http://tom.preston-werner.com
> github.com/mojombo
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>
--
Jared "Lucky" Kuolt