Partial Call Results about wamp-proto HOT 5 CLOSED

It would be valuable to have a proper use case for a message exchange pattern like this in the first place.

The only use case I can think of is: the RPC performs a database query which is long-running and/or produces a large result set. "Streaming" or sending the result to such an RPC in parts could be useful.

On the other hand: I'm not sure if above is sufficient when the goal is "seamless database access". IOW: we might as well first look at i.e. PostgreSQLs database protocol and how it's structured.

from wamp-proto.

Here is my personal use case :

I have a p2p design with multiple clients and 1 central server. When a client connect to the central server, the central server will send him back the connection information of all clients connected. Because of timeout, I don't want my central server to send the complete list of clients but one result per client instead.

This behavior can be obtained with a pub/sub but it's lighter and easier with a RPC.

I could think about more use case with streaming needs like you said. Auto completion can be a good example, we rather want fast response than complete response.

The last use case I can think of is for very large response. Split it in small pieces this way if the connection break you can restart at a specific result instead of start over. It could be a unnecessary override of HTTP capabilities.

The question about CallError breaking the communication need a CallError define first.
Is CallError result only used for wamp related error or can it be used by the final action ?

from wamp-proto.

Your first use case might also be implemented similar to how paged queries are done: Do a number of RPC which have a "start" and "limit" parameter, and the RPC only returning "sessions[start:start+limit]".

For auto-completion, not only the results needed to arrive incrementally, but also the call argument changes: as the user types character by character, that search string is changing. That would involve changing a RPC call args after the call was started. I can see the use case (definitely), but changing an RPC call args after start seems ... exotic;)

For very large result sets, again, the one option is to have streaming results, but the other would be paged queries. That has the advantage that a client can just stop issueing new RPC for another page (part) of the result, wheras with streaming, how can the client stop the server from sending more and more?

A major problem is technical: Python/Twisted Deferreds don't have a progress callback (as commonly used JS Deferreds like from when.js, jQuery Deferred or Promise/A). AutobahnPython RPCs return a Twisted Deferred. There is no progress callback, and a success/failure can only be signaled once. In essence it would require a major break of the API.

from wamp-proto.

Added to WAMPv2 spec: new CALL_PROGRESS message. For Twisted, we will need a Deferred derived from the the Twisted class which adds machinery for progressive results.

from wamp-proto.

WAMPv2 has:

[CALL_PROGRESS,     Request|id]
[CALL_PROGRESS,     Request|id, CallProgress|any]

Implementations that want to support this will need a progress callback on their Deferred/ Promise

from wamp-proto.