On the future / stability of Crossbar and Autobahn

#1

Hi all,

I’ve spent most of this spring implementing a prototype for remote control and sensing of a machine for mineral analysis we’re developing at work. The system is based on Crossbar and Autobahn. The machine contains a variety of devices such as motors, spectrometers, an xray source and an image detector.

After a meeting yesterday we’ve now decided to go ahead and take this further, and actually use this system in the final product, which is due to be released some time in Q2 2016. The software parts will hopefully be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations (mines) and will only be serviced once a year, it’s of utmost importance that the solution is robust.

As such I have three questions:

  • How far is Crossbar and Autobahn from a 1.0 release?

  • What kind of API / behavioral stability promises does Crossbar / Autobahn have? Does it use a semantic version scheme?

  • Do you think call timeouts will be stable in the WAMP spec by the time Crossbar/Autobahn is release, and will it support it?

Cheers,

Elvis

0 Likes

#2

Hi all,

I’ve spent most of this spring implementing a prototype for remote control and sensing of a machine for mineral analysis we’re developing at work. The system is based on Crossbar and Autobahn. The machine contains a variety of devices such as motors, spectrometers, an xray source and an image detector.

After a meeting yesterday we’ve now decided to go ahead and take this further, and actually use this system in the final product, which is due to be released some time in Q2 2016. The software parts will hopefully be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations (mines) and will only be serviced once a year, it’s of utmost importance that the solution is robust.

As such I have three questions:

  • How far is Crossbar and Autobahn from a 1.0 release?
  • What kind of API / behavioral stability promises does Crossbar / Autobahn have? Does it use a semantic version scheme?
  • Do you think call timeouts will be stable in the WAMP spec by the time Crossbar/Autobahn is release, and will it support it?

Should have been “[…] Crossbar/Autobahn 1.0 is released […]”.

Elvis

···

On Wednesday, June 17, 2015 at 11:15:50 AM UTC+2, Elvis Stansvik wrote:

Cheers,

Elvis

0 Likes

#3

Hi Elvis,

Hi all,

I've spent most of this spring implementing a prototype for remote
control and sensing of a machine for mineral analysis we're developing
at work. The system is based on Crossbar and Autobahn. The machine

AutobahnPython that is?

Is that running Linux? x86, ARM? CPython or PyPy?

contains a variety of devices such as motors, spectrometers, an xray
source and an image detector.

Sounds pretty high-tech!

After a meeting yesterday we've now decided to go ahead and take this
further, and actually use this system in the final product, which is due

Awesome;)

to be released some time in Q2 2016. The software parts will hopefully
be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations
(mines) and will only be serviced once a year, it's of utmost importance
that the solution is robust.

So any updates can only be applied once a year?

The machine hasn't any connectivity on it's own?

As such I have three questions:

  - How far is Crossbar and Autobahn from a 1.0 release?

People are using Crossbar.io and AutobahnPython in production already today. The code is pretty robust and works, but on the other hand, we are not yet 1.0, since API and feature-sets are still a little in flux.

So the main thing 1.0 releases will bring is: API and feature stability.

AutobahnPython is quite close to 1.0. We have a "meta issue" here:

https://github.com/tavendo/AutobahnPython/issues/313

Apart from a handful of features we still need (auto-reconn., call timeouts and such), we are considering some cleanups in the API, such as using PEP8 naming.

  - What kind of API / behavioral stability promises does Crossbar /
Autobahn have? Does it use a semantic version scheme?

For 1.0, we will have a proper documentation of "public/supported API", and likely will _then_ follow semver

https://github.com/tavendo/AutobahnPython/issues/313

Feel free to comment on that issue (also)!

  - Do you think call timeouts will be stable in the WAMP spec by the
time Crossbar/Autobahn is release, and will it support it?

Yes, definitely. Call timeouts are (obviously) important. We'll have it.

Cheers,
/Tobias

···

Am 17.06.2015 um 11:15 schrieb Elvis Stansvik:

Cheers,
Elvis

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com
<mailto:autobahnws+...@googlegroups.com>.
To post to this group, send email to autob...@googlegroups.com
<mailto:autob...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com
<https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#4

Hi Tobias, and sorry for the late reply.

Hi Elvis,

Hi all,

I’ve spent most of this spring implementing a prototype for remote

control and sensing of a machine for mineral analysis we’re developing

at work. The system is based on Crossbar and Autobahn. The machine

AutobahnPython that is?

Yep, AutobahnPython.

Is that running Linux? x86, ARM? CPython or PyPy?

Linux, x86, CPython.

PyPy might be something we investigate before (or after) launch, but we have no pressing need to do so at this time (and might never have actually, as Python execution time is not a bottle neck).

contains a variety of devices such as motors, spectrometers, an xray

source and an image detector.

Sounds pretty high-tech!

:slight_smile:

After a meeting yesterday we’ve now decided to go ahead and take this

further, and actually use this system in the final product, which is due

Awesome;)

to be released some time in Q2 2016. The software parts will hopefully

be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations

(mines) and will only be serviced once a year, it’s of utmost importance

that the solution is robust.

So any updates can only be applied once a year?

As a rule, yes, software updates will only be applied when then machine is taken in for its yearly service.

The machine hasn’t any connectivity on it’s own?

Most units will operate in an environment where there’s no connectivity (various drill sites, down next to the bore holes), and will also move around quite regularly. Some large sites may have connectivity, but it’s nothing we can count on.

As such I have three questions:

  • How far is Crossbar and Autobahn from a 1.0 release?

People are using Crossbar.io and AutobahnPython in production already
today. The code is pretty robust and works, but on the other hand, we
are not yet 1.0, since API and feature-sets are still a little in flux.

So the main thing 1.0 releases will bring is: API and feature stability.

Ah. That’s good to know.

AutobahnPython is quite close to 1.0. We have a “meta issue” here:

https://github.com/tavendo/AutobahnPython/issues/313

Apart from a handful of features we still need (auto-reconn., call
timeouts and such), we are considering some cleanups in the API, such as
using PEP8 naming.

Okay. All of those are of interest to us I think.

  • What kind of API / behavioral stability promises does Crossbar /

Autobahn have? Does it use a semantic version scheme?

For 1.0, we will have a proper documentation of “public/supported API”,
and likely will then follow semver

Alright. Makes sense.

https://github.com/tavendo/AutobahnPython/issues/313

Feel free to comment on that issue (also)!

Thanks for the link. Will take a look as soon as I have time.

  • Do you think call timeouts will be stable in the WAMP spec by the

time Crossbar/Autobahn is release, and will it support it?

Yes, definitely. Call timeouts are (obviously) important. We’ll have it.

Great to hear that.

Thanks a lot for the answers Tobias.

Elvis

···

On Wednesday, June 17, 2015 at 7:01:39 PM UTC+2, Tobias Oberstein wrote:

Am 17.06.2015 um 11:15 schrieb Elvis Stansvik:

Cheers,

/Tobias

Cheers,

Elvis

You received this message because you are subscribed to the Google

Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to autobahnws+...@googlegroups.com

mailto:autobahnws+unsub...@googlegroups.com.

To post to this group, send email to auto...@googlegroups.com

mailto:autob...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com

<https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#5

Just two follow-up question that popped up:

  1. Do you have any rough schedule, or maybe just hopes (you must have that :slight_smile: ), for when 1.0 of Autobahn and/or Crossbar could be released? It would of course be interesting to see how those releases relates to our own schedule for the final product.

  2. As these pre-1.0 releases come out (0.10.x et.c.), I can see that for the most part they are announced on the mailing lists (was e.g. Crossbar 0.10.4 / Autobahn 0.10.4 announced though?). Would it be possible to also include info on any API breakages in the release? Or is that too much release overhead at this point? If so we’ll just “upgrade and test”, which should be fine as we aim for 100% line coverage. It would just be nice to have a heads up on what to expect after an upgrade.

Elvis

···

On Monday, June 22, 2015 at 11:09:35 AM UTC+2, Elvis Stansvik wrote:

Hi Tobias, and sorry for the late reply.

On Wednesday, June 17, 2015 at 7:01:39 PM UTC+2, Tobias Oberstein wrote:

Hi Elvis,

Am 17.06.2015 um 11:15 schrieb Elvis Stansvik:

Hi all,

I’ve spent most of this spring implementing a prototype for remote

control and sensing of a machine for mineral analysis we’re developing

at work. The system is based on Crossbar and Autobahn. The machine

AutobahnPython that is?

Yep, AutobahnPython.

Is that running Linux? x86, ARM? CPython or PyPy?

Linux, x86, CPython.

PyPy might be something we investigate before (or after) launch, but we have no pressing need to do so at this time (and might never have actually, as Python execution time is not a bottle neck).

contains a variety of devices such as motors, spectrometers, an xray

source and an image detector.

Sounds pretty high-tech!

:slight_smile:

After a meeting yesterday we’ve now decided to go ahead and take this

further, and actually use this system in the final product, which is due

Awesome;)

to be released some time in Q2 2016. The software parts will hopefully

be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations

(mines) and will only be serviced once a year, it’s of utmost importance

that the solution is robust.

So any updates can only be applied once a year?

As a rule, yes, software updates will only be applied when then machine is taken in for its yearly service.

The machine hasn’t any connectivity on it’s own?

Most units will operate in an environment where there’s no connectivity (various drill sites, down next to the bore holes), and will also move around quite regularly. Some large sites may have connectivity, but it’s nothing we can count on.

As such I have three questions:

  • How far is Crossbar and Autobahn from a 1.0 release?

People are using Crossbar.io and AutobahnPython in production already
today. The code is pretty robust and works, but on the other hand, we
are not yet 1.0, since API and feature-sets are still a little in flux.

So the main thing 1.0 releases will bring is: API and feature stability.

Ah. That’s good to know.

AutobahnPython is quite close to 1.0. We have a “meta issue” here:

https://github.com/tavendo/AutobahnPython/issues/313

Apart from a handful of features we still need (auto-reconn., call
timeouts and such), we are considering some cleanups in the API, such as
using PEP8 naming.

Okay. All of those are of interest to us I think.

  • What kind of API / behavioral stability promises does Crossbar /

Autobahn have? Does it use a semantic version scheme?

For 1.0, we will have a proper documentation of “public/supported API”,
and likely will then follow semver

Alright. Makes sense.

https://github.com/tavendo/AutobahnPython/issues/313

Feel free to comment on that issue (also)!

Thanks for the link. Will take a look as soon as I have time.

  • Do you think call timeouts will be stable in the WAMP spec by the

time Crossbar/Autobahn is release, and will it support it?

Yes, definitely. Call timeouts are (obviously) important. We’ll have it.

Great to hear that.

Thanks a lot for the answers Tobias.

Elvis

Cheers,

/Tobias

Cheers,

Elvis

You received this message because you are subscribed to the Google

Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to autobahnws+...@googlegroups.com

mailto:autobahnws+unsub...@googlegroups.com.

To post to this group, send email to auto...@googlegroups.com

mailto:autob...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com

<https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#6

Hi Elivs,

we’ll try to list any API breakages in the release notes (this really is something which should be in there).

regards,

Alex

···

Am Montag, 22. Juni 2015 11:29:07 UTC+2 schrieb Elvis Stansvik:

Just two follow-up question that popped up:

  1. Do you have any rough schedule, or maybe just hopes (you must have that :slight_smile: ), for when 1.0 of Autobahn and/or Crossbar could be released? It would of course be interesting to see how those releases relates to our own schedule for the final product.
  1. As these pre-1.0 releases come out (0.10.x et.c.), I can see that for the most part they are announced on the mailing lists (was e.g. Crossbar 0.10.4 / Autobahn 0.10.4 announced though?). Would it be possible to also include info on any API breakages in the release? Or is that too much release overhead at this point? If so we’ll just “upgrade and test”, which should be fine as we aim for 100% line coverage. It would just be nice to have a heads up on what to expect after an upgrade.

Elvis

On Monday, June 22, 2015 at 11:09:35 AM UTC+2, Elvis Stansvik wrote:

Hi Tobias, and sorry for the late reply.

On Wednesday, June 17, 2015 at 7:01:39 PM UTC+2, Tobias Oberstein wrote:

Hi Elvis,

Am 17.06.2015 um 11:15 schrieb Elvis Stansvik:

Hi all,

I’ve spent most of this spring implementing a prototype for remote

control and sensing of a machine for mineral analysis we’re developing

at work. The system is based on Crossbar and Autobahn. The machine

AutobahnPython that is?

Yep, AutobahnPython.

Is that running Linux? x86, ARM? CPython or PyPy?

Linux, x86, CPython.

PyPy might be something we investigate before (or after) launch, but we have no pressing need to do so at this time (and might never have actually, as Python execution time is not a bottle neck).

contains a variety of devices such as motors, spectrometers, an xray

source and an image detector.

Sounds pretty high-tech!

:slight_smile:

After a meeting yesterday we’ve now decided to go ahead and take this

further, and actually use this system in the final product, which is due

Awesome;)

to be released some time in Q2 2016. The software parts will hopefully

be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations

(mines) and will only be serviced once a year, it’s of utmost importance

that the solution is robust.

So any updates can only be applied once a year?

As a rule, yes, software updates will only be applied when then machine is taken in for its yearly service.

The machine hasn’t any connectivity on it’s own?

Most units will operate in an environment where there’s no connectivity (various drill sites, down next to the bore holes), and will also move around quite regularly. Some large sites may have connectivity, but it’s nothing we can count on.

As such I have three questions:

  • How far is Crossbar and Autobahn from a 1.0 release?

People are using Crossbar.io and AutobahnPython in production already
today. The code is pretty robust and works, but on the other hand, we
are not yet 1.0, since API and feature-sets are still a little in flux.

So the main thing 1.0 releases will bring is: API and feature stability.

Ah. That’s good to know.

AutobahnPython is quite close to 1.0. We have a “meta issue” here:

https://github.com/tavendo/AutobahnPython/issues/313

Apart from a handful of features we still need (auto-reconn., call
timeouts and such), we are considering some cleanups in the API, such as
using PEP8 naming.

Okay. All of those are of interest to us I think.

  • What kind of API / behavioral stability promises does Crossbar /

Autobahn have? Does it use a semantic version scheme?

For 1.0, we will have a proper documentation of “public/supported API”,
and likely will then follow semver

Alright. Makes sense.

https://github.com/tavendo/AutobahnPython/issues/313

Feel free to comment on that issue (also)!

Thanks for the link. Will take a look as soon as I have time.

  • Do you think call timeouts will be stable in the WAMP spec by the

time Crossbar/Autobahn is release, and will it support it?

Yes, definitely. Call timeouts are (obviously) important. We’ll have it.

Great to hear that.

Thanks a lot for the answers Tobias.

Elvis

Cheers,

/Tobias

Cheers,

Elvis

You received this message because you are subscribed to the Google

Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to autobahnws+...@googlegroups.com

mailto:autobahnws+unsub...@googlegroups.com.

To post to this group, send email to auto...@googlegroups.com

mailto:autob...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com

<https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#7

Hi Elivs,

we’ll try to list any API breakages in the release notes (this really is something which should be in there).

Thanks, much appriciated!

Elvis

···

On Friday, June 26, 2015 at 4:46:12 PM UTC+2, Alexander Gödde wrote:

regards,

Alex

Am Montag, 22. Juni 2015 11:29:07 UTC+2 schrieb Elvis Stansvik:

Just two follow-up question that popped up:

  1. Do you have any rough schedule, or maybe just hopes (you must have that :slight_smile: ), for when 1.0 of Autobahn and/or Crossbar could be released? It would of course be interesting to see how those releases relates to our own schedule for the final product.
  1. As these pre-1.0 releases come out (0.10.x et.c.), I can see that for the most part they are announced on the mailing lists (was e.g. Crossbar 0.10.4 / Autobahn 0.10.4 announced though?). Would it be possible to also include info on any API breakages in the release? Or is that too much release overhead at this point? If so we’ll just “upgrade and test”, which should be fine as we aim for 100% line coverage. It would just be nice to have a heads up on what to expect after an upgrade.

Elvis

On Monday, June 22, 2015 at 11:09:35 AM UTC+2, Elvis Stansvik wrote:

Hi Tobias, and sorry for the late reply.

On Wednesday, June 17, 2015 at 7:01:39 PM UTC+2, Tobias Oberstein wrote:

Hi Elvis,

Am 17.06.2015 um 11:15 schrieb Elvis Stansvik:

Hi all,

I’ve spent most of this spring implementing a prototype for remote

control and sensing of a machine for mineral analysis we’re developing

at work. The system is based on Crossbar and Autobahn. The machine

AutobahnPython that is?

Yep, AutobahnPython.

Is that running Linux? x86, ARM? CPython or PyPy?

Linux, x86, CPython.

PyPy might be something we investigate before (or after) launch, but we have no pressing need to do so at this time (and might never have actually, as Python execution time is not a bottle neck).

contains a variety of devices such as motors, spectrometers, an xray

source and an image detector.

Sounds pretty high-tech!

:slight_smile:

After a meeting yesterday we’ve now decided to go ahead and take this

further, and actually use this system in the final product, which is due

Awesome;)

to be released some time in Q2 2016. The software parts will hopefully

be finished during the autumn.

Since the machine will be placed in remote and inaccessible locations

(mines) and will only be serviced once a year, it’s of utmost importance

that the solution is robust.

So any updates can only be applied once a year?

As a rule, yes, software updates will only be applied when then machine is taken in for its yearly service.

The machine hasn’t any connectivity on it’s own?

Most units will operate in an environment where there’s no connectivity (various drill sites, down next to the bore holes), and will also move around quite regularly. Some large sites may have connectivity, but it’s nothing we can count on.

As such I have three questions:

  • How far is Crossbar and Autobahn from a 1.0 release?

People are using Crossbar.io and AutobahnPython in production already
today. The code is pretty robust and works, but on the other hand, we
are not yet 1.0, since API and feature-sets are still a little in flux.

So the main thing 1.0 releases will bring is: API and feature stability.

Ah. That’s good to know.

AutobahnPython is quite close to 1.0. We have a “meta issue” here:

https://github.com/tavendo/AutobahnPython/issues/313

Apart from a handful of features we still need (auto-reconn., call
timeouts and such), we are considering some cleanups in the API, such as
using PEP8 naming.

Okay. All of those are of interest to us I think.

  • What kind of API / behavioral stability promises does Crossbar /

Autobahn have? Does it use a semantic version scheme?

For 1.0, we will have a proper documentation of “public/supported API”,
and likely will then follow semver

Alright. Makes sense.

https://github.com/tavendo/AutobahnPython/issues/313

Feel free to comment on that issue (also)!

Thanks for the link. Will take a look as soon as I have time.

  • Do you think call timeouts will be stable in the WAMP spec by the

time Crossbar/Autobahn is release, and will it support it?

Yes, definitely. Call timeouts are (obviously) important. We’ll have it.

Great to hear that.

Thanks a lot for the answers Tobias.

Elvis

Cheers,

/Tobias

Cheers,

Elvis

You received this message because you are subscribed to the Google

Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to autobahnws+...@googlegroups.com

mailto:autobahnws+unsub...@googlegroups.com.

To post to this group, send email to auto...@googlegroups.com

mailto:autob...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com

<https://groups.google.com/d/msgid/autobahnws/8ed42d6e-a139-4258-8f7f-cb5789ae0825%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

0 Likes