AutobahnPython: frame-based / streaming WebSocket API - possible deprecation

#1

Hi,

I wonder if anybody out there actually uses the following two features supported by AutobahnPython:

WebSocket Frame-based API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelFrameApi

WebSocket Streaming API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelStreamingApi

We have examples of how these APIs can be used:

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/websocket/streaming

Any users out there?

My personal view is this:

1)
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.

2)
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.

Cheers,
/Tobias

0 Likes

#2

Hi Tobias,

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
(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.

Incidentally, thanks for all your work on Autobahn/Crossbar/WAMP --
I think it will be exactly what I need (both rpc and pub/sub).

Cheers,
Steve Waterbury

···

On 09/15/2015 03:34 AM, Tobias Oberstein wrote:

Hi,

I wonder if anybody out there actually uses the following two features
supported by AutobahnPython:

WebSocket Frame-based API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelFrameApi

WebSocket Streaming API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelStreamingApi

We have examples of how these APIs can be used:

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/websocket/streaming

Any users out there?

My personal view is this:

1)
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.

2)
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.

Cheers,
/Tobias

0 Likes

#3

Hi Steve,

thanks for feedback!

Hi Tobias,

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 ..

Cheers,
/Tobias

Cheers,
Steve Waterbury

On 09/15/2015 03:34 AM, Tobias Oberstein wrote:

Hi,

I wonder if anybody out there actually uses the following two features
supported by AutobahnPython:

WebSocket Frame-based API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelFrameApi

WebSocket Streaming API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelStreamingApi

We have examples of how these APIs can be used:

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/websocket/streaming

Any users out there?

My personal view is this:

1)
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.

2)
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.

Cheers,
/Tobias

0 Likes

#4

Thanks for the clarification, Tobias! Yes, since I plan to use
WAMP (and not "raw" websockets), I will not need the direct
websockets streaming API, just the WAMP one. What you say makes
sense -- since the WAMP infrastructure's most important use cases
are IoT-related, those would be the ones in which the clients are
most often *not* browsers, I would guess ... :slight_smile:

···

On 09/15/2015 10:03 AM, Tobias Oberstein wrote:

Hi Steve,

thanks for feedback!

Am 15.09.2015 um 15:12 schrieb Steve Waterbury:

Hi Tobias,

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.

==

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 ..

Cheers,
/Tobias

Cheers,
Steve Waterbury

On 09/15/2015 03:34 AM, Tobias Oberstein wrote:

Hi,

I wonder if anybody out there actually uses the following two features
supported by AutobahnPython:

WebSocket Frame-based API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelFrameApi

WebSocket Streaming API:

http://autobahn.ws/python/reference/autobahn.websocket.html#autobahn.websocket.interfaces.IWebSocketChannelStreamingApi

We have examples of how these APIs can be used:

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/websocket/streaming

Any users out there?

My personal view is this:

1)
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.

2)
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.

Cheers,
/Tobias

0 Likes