thanks for feedback!
I am planning to use AutobahnPython in an application I'm developing
that will have a Python gui client (qt-based) communicating via
crossbar. While I don't have a specific requirement yet for the
streaming API, it could be very useful down the road. This scenario
Streaming mass data over _WAMP_ is yet another thing.
I do understand that people want to use WAMP for all kinds of stuff, including mass data transfer (files). Partially, we can already do this in WAMP. Well, it needs WAMP router support for this feature:
progressive call results
Crossbar.io has that. What's missing is "progressive calls".
It would take too long to discuss all this, and how that is different from the _WebSocket_ streaming API thing I was raising ..
(owning both ends of the wire and using Python at both ends) is
currently the only one that would justify keeping the streaming API,
so I understand if one (possible) application is not sufficient
justification for maintaining it.
See above ^
If you are using WAMP and Crossbar.io, we have this (partically) addressed, and in any case, and it runs deeper and is independent of the streaming WebSocket API.
Am 15.09.2015 um 15:12 schrieb Steve Waterbury:
What we currently do in AutobahnPython is a "big cleanup". As the library is used more and more in critical systems and people _depend_ on it, it's important to have a stable API which is small enough so we can provide 100% robustness and stability.
Currently, AutobahnPython has grown a bit unwieldly (it's more than 10k LOCs without empty lines / comments) .. historic reasons, and the fact that it does a lot. We need to cut it down a little to tame it ..
Incidentally, thanks for all your work on Autobahn/Crossbar/WAMP --
I think it will be exactly what I need (both rpc and pub/sub).
Great! Please post here if you have Qs or want to report successes or tell us more about what you do ..
On 09/15/2015 03:34 AM, Tobias Oberstein wrote:
I wonder if anybody out there actually uses the following two features
supported by AutobahnPython:
WebSocket Frame-based API:
WebSocket Streaming API:
We have examples of how these APIs can be used:
Any users out there?
My personal view is this:
The frame-based API is mostly esoteric .. it exposes a WebSocket
internal artifact (WebSocket frames). I can't come up with a legimate
use case (for app/user code). The API should just die.
There are valid use case for the streaming-API in principle. E.g.
transferring big amounts of data, like files or media over WebSocket.
The practical problems are:
- AutobahnPython is pretty much the only WebSocket implementation I know
about that provides a streaming WS API
- in particular, there is no browser API available
Unless some users step up, I tend to support removing both the
frame-based and streaming API moving forward.