Free advertising and API suggestion

#1

Hi,

I have been wandering around for some time, and was quite disapointed nobody talked more about crossbar in the Python community. It’s awesome.

I think one of the reason is that it’s hard to understand what you can do with it when visiting the official website.

I tried to be of a bit of help by writting a long article (in french) about it :

http://sametmax.com/crossbar-le-futur-des-applications-web-python/

My blog got 3000-4000 hits each day and is followed by a lot of people in the french Python community, so it should help.

But it’s not enough.

We should make some kind of presentation (maybe a video, or at least a slide show) to explain what is WAMP, crossbar, what problems it solves and how. It needs more schemas of components talking to each others, uses cases, comparison to AMQP, SockJS, supervisor and the like…

Of course the documentation itself is quite hard to read, but you already asked for help about that so I guess it’s up to us to improve it (that’s what FOSS is for after all).

What I think is the biggest adoption issue, however, is the API. Autobahn should have a small cost of entry, and right now it doesnt. The hello world is not only hard to write using the documentation, but quite scary :

from twisted.python import log
from twisted.internet.defer import inlineCallbacks
 
from autobahn.twisted.wamp import ApplicationSession
from autobahn.twisted.wamp import ApplicationRunner
 
class ListenForEvent(ApplicationSession)
    :
 
def __init__(self, config)        :
ApplicationSession.__init__(self)
        self.config = config
 
def onConnect(self)        :
self.join(self.config.realm)
 
@inlineCallbacks
def onJoin(self, details)        :
callback = lambda x: log.msg("Received event %s" % x)
        yield self.subscribe(callback, 'un_evenement')
 
if __name__ == '__main__'   :
runner = ApplicationRunner(endpoint="tcp:127.0.0.1:8080"                              ,
url="ws://localhost:8080/ws"                              ,
realm="realm1")
   runner.run(ListenForEvent)

We need a simplified wrapper for that, that can be used for simple use case : small applications, tests, etc. In the same fashion that flask and bottle make web programming much easier than Django.

I’m suggesting to add something like this :

from autobahn.app import App
 
app = App(url="ws://localhost:8080/ws")
 
@event("event_name")
def handle(details)    :
app.log("Received event %s" % details)
 
if __name__ == '__main__'   :
app.run()

Sane defaults, doesn’t not cover all the use cases, but it’s enought for 80% of the dev. The goal is not to replace the other API, but rather offer something higher level we can show of in the first page of the documentation that would make people started quickly.

Regards

0 Likes

#2

Hi Michel!

Thanks for your input - and for the blog post. (And I always welcome an opportunity to dust off my high school French.)

Your enthusiasm in the post is wonderful - and I can understand your frustration, especially with the state of the documentation.

I’m wondering: Could I translate your post into English and publish it on the Tavendo blog (http://tavendo.com/blog/)? Would be nice to have an outside perspective there.

If this would be OK in principle, then I’d of course send the translation to you for your OK before publishing. (My French is OK for simple reading, or in cases where I already understand the subject matter well, but there may, of course, be mistakes.)

Best regards,

Alex

···

Am Sonntag, 25. Mai 2014 12:39:23 UTC+2 schrieb Michel Desmoulin:

Hi,

I have been wandering around for some time, and was quite disapointed nobody talked more about crossbar in the Python community. It’s awesome.

I think one of the reason is that it’s hard to understand what you can do with it when visiting the official website.

I tried to be of a bit of help by writting a long article (in french) about it :

http://sametmax.com/crossbar-le-futur-des-applications-web-python/

My blog got 3000-4000 hits each day and is followed by a lot of people in the french Python community, so it should help.

But it’s not enough.

We should make some kind of presentation (maybe a video, or at least a slide show) to explain what is WAMP, crossbar, what problems it solves and how. It needs more schemas of components talking to each others, uses cases, comparison to AMQP, SockJS, supervisor and the like…

Of course the documentation itself is quite hard to read, but you already asked for help about that so I guess it’s up to us to improve it (that’s what FOSS is for after all).

What I think is the biggest adoption issue, however, is the API. Autobahn should have a small cost of entry, and right now it doesnt. The hello world is not only hard to write using the documentation, but quite scary :

from twisted.python import log
from twisted.internet.defer import inlineCallbacks
 
from autobahn.twisted.wamp import ApplicationSession
from autobahn.twisted.wamp import ApplicationRunner
 
class ListenForEvent(ApplicationSession)
    :
 
def __init__(self, config)        :
ApplicationSession.__init__(self)
        self.config = config
 
def onConnect(self)        :
self.join(self.config.realm)
 
@inlineCallbacks
def onJoin(self, details)        :
callback = lambda x: log.msg("Received event %s" % x)
        yield self.subscribe(callback, 'un_evenement')
 
if __name__ == '__main__'   :
runner = ApplicationRunner(endpoint="tcp:[127.0.0.1:8080](http://127.0.0.1:8080)"                              ,
url="ws://localhost:8080/ws"                              ,
realm="realm1")
   runner.run(ListenForEvent)

We need a simplified wrapper for that, that can be used for simple use case : small applications, tests, etc. In the same fashion that flask and bottle make web programming much easier than Django.

I’m suggesting to add something like this :

from autobahn.app import App
 
app = App(url="ws://localhost:8080/ws")
 
@event("event_name")
def handle(details)    :
app.log("Received event %s" % details)
 
if __name__ == '__main__'   :
app.run()

Sane defaults, doesn’t not cover all the use cases, but it’s enought for 80% of the dev. The goal is not to replace the other API, but rather offer something higher level we can show of in the first page of the documentation that would make people started quickly.

Regards

0 Likes

#3

Hi Michel,

thanks for your feedback and suggestions - highly welcome!

Hi,

I have been wandering around for some time, and was quite disapointed
nobody talked more about crossbar in the Python community. It's awesome.

Yeah;) It's still a very young project, but has potential - IMHO.

I think one of the reason is that it's hard to understand what you can
do with it when visiting the official website.

I agree. The Crossbar Web site is .. well, merely more than a landing page right now. Feeling guilty :frowning:

I tried to be of a bit of help by writting a long article (in french)
about it :

http://sametmax.com/crossbar-le-futur-des-applications-web-python/

Oh, nice!!

I've been reading the post (well, a translation by Google translate;) - and I agree with the critique .. powerful, but complex to grasp .. inadequate documentation .. asynchronous programming / Twisted being a high barrier.

Those issues can be (and of course should be) fixed.

A comment regarding Twisted: while using plain Deferreds is better than a pure callback mess, it still has a learning curve. I agree. Personally, I've got my brain twisted now, so it feels natural. But it took some time.

Another note: NodeJS is only right now moving from spaghetti callback style to Deferreds (promises in JS land).

BUT: there is something even better (for some .. ask Guido or Glyph .. you'll get different answers probably): co-routines ("yield").

Coroutines essentially make your code look synchronous at surface

https://github.com/tavendo/AutobahnPython/blob/master/examples/twisted/wamp/basic/rpc/slowsquare/backend.py#L41

but still work asynchronous under the hood.

Twisted has that. And asyncio makes that style the recommended default. And AutobahnPython supports all of those.

Hence, you can write WAMP components in pure Python 3.4 (no Twisted) using co-routines.

My blog got 3000-4000 hits each day and is followed by a lot of people
in the french Python community, so it should help.

Huh;) That's something. You seem to be well connected in the community. You offering free evangelization of Crossbar - makes me happy;) Thanks!

But it's not enough.

We should make some kind of presentation (maybe a video, or at least a
slide show) to explain what is WAMP, crossbar, what problems it solves
and how. It needs more schemas of components talking to each others,
uses cases, comparison to AMQP, SockJS, supervisor and the like...

Absolutely. I have added

https://github.com/crossbario/crossbar/issues/56

to track

Of course the documentation itself is quite hard to read, but you
already asked for help about that so I guess it's up to us to improve it
(that's what FOSS is for after all).

Yep. Documentation, testing and promotion .. we could use any kind of help.

I've been trying to keep up at least the Wiki pages

https://github.com/crossbario/crossbar/wiki

But even those are right now incomplete and partially out of date. The code base is still moving fast. We are still catching up with features that were in the predecessor of Crossbar (closed source Tavendo WebMQ).

What I think is the biggest adoption issue, however, is the API.

... snip ...

I'm suggesting to add something like this :

from autobahn.app import App

app = App(url="ws://localhost:8080/ws")

@event("event_name")
def handle(details):
     app.log("Received event %s" % details)

if __name__ =='__main__':
    app.run()

That looks indeed somewhat simpler .. and probably really the minimum code. Could work. We could put that on top of ApplicationRunner:

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

Thing is: for Crossbar being able to host components, it needs to have a user function that creates an instance of ApplicationSession upon request right now.

We probably could make it such that Crossbar could also digest a global object like "app" above.

Personally, I have a strong aversion against anything global. I was sceptical with Flask at first sight when I saw the global "app" thing.

Maybe my background in C/C++ .. globals will come back biting you sooner or later.

But at least in Python land for those that know Flask and the like, having an "app" global thing probably feels more "at home" than defining an exported factory that'll create app sessions.

Sane defaults, doesn't not cover all the use cases, but it's enought for
80% of the dev. The goal is not to replace the other API, but rather
offer something higher level we can show of in the first page of the
documentation that would make people started quickly.

Yes. A first visitor getting started can't be simple enough. Thinking about it, I came up with another idea to simplify matters:

https://github.com/crossbario/crossbar/issues/57

···

Am 25.05.2014 12:39, schrieb Michel Desmoulin:

===

Alright, Michel, thank you very much for feedback, ideas - and offering help! Cheers,

/Tobias

Regards

--
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#4

I'm suggesting to add something like this :

from autobahn.app import App

app = App(url="ws://localhost:8080/ws")

@event("event_name")def handle(details):
    app.log("Received event %s" % details)
if __name__ == '__main__':
   app.run()

That's how websocket for Flask works more or less I believe. It's a simple
dispatching mechanism that works well indeed. I used it with my XMPP
library years ago.

···

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

0 Likes

#5

Hi Sylvain,

    I'm suggesting to add something like this :

    from autobahn.app import App

    app = App(url="ws://localhost:8080/ws")

    @event("event_name")
    def handle(details):
         app.log("Received event %s" % details)

    if __name__ =='__main__':
        app.run()

That's how websocket for Flask works more or less I believe. It's a

Are you referring to

http://www.kennethreitz.org/essays/introducing-flask-sockets

?

If so, couple of comments (from my scatchy understanding of flask-sockets .. I have only looked at it right now):

1) It depends on gevent and running Flask under a gevent-based WSGI container. FWIW, Twisted can act as a WSGI container as well (it runs WSGI on a background worker thread pool).

Are most people using Flask ready to run gevent? Or do they mostly run (and are sticked to) something like Apache/mod_wsgi? Or what are people using for production?

2) The route decorators in flask-sockets are routes for _HTTP URLs_.

E.g.

@sockets.route('/echo')
def echo_socket(ws):
     while True:
         message = ws.receive()
         ws.send(message)

while the

@event("event_name")

"route" in the example of Michel is a _WAMP Topic_.

3)
What you can do with Crossbar already today is the following.

Here is part of a Crossbar (transport) config that runs 2 "path services" (static and websocket/wamp):

{
    "type": "web",
    "endpoint": {
       "type": "tcp",
       "port": 8080
    },
    "paths": {
       "/": {
          "type": "static",
          "directory": "/home/user/docroot"
       },
       "wamp": {
          "type": "websocket"
          ...
       }
    }
}

And you can plug in Flask (or any WSGI app) into that Web resource tree

https://github.com/crossbario/crossbar/wiki/WSGI-Host-Service

as well as a couple of other path services:

https://github.com/crossbario/crossbar/wiki/Web-Transports-and-Services#path-services

4)
As far as I can see, there are at least 2 missing pieces:

a) You not only want to run WSGI and WAMP components under 1 server (side-by-side), but you want to closely integrate (e.g. publish a WAMP event from within the _WSGI_ code).

b) You are unwilling/unable to even run your WSGI app under Twisted. That is, need an external bridge (most probably WAMP <-> REST).

5)
FWIW, my personal approach to Web apps these days is different: single page Web apps (everything static, CDN hosted, or baked into mobile app with Cordova) + "headless" WAMP components. So I don't have the need for some dynamic HTML generator anymore.

But of course I acknowledge this won't be for everyone.

So yes, totally, I think we need better bridging of Crossbar with Django, Flask, etc.

This is an interesting thread, thanks!

/Tobias

···

Am 25.05.2014 18:36, schrieb Sylvain Hellegouarch:

simple dispatching mechanism that works well indeed. I used it with my
XMPP library years ago.

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

--
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#6

Hi Tobias,

···

As far as I can see, there are at least 2 missing pieces:

a) You not only want to run WSGI and WAMP components under 1 server (side-by-side), but you want to closely integrate (e.g. publish a WAMP event from within the WSGI code).

b) You are unwilling/unable to even run your WSGI app under Twisted. That is, need an external bridge (most probably WAMP <-> REST).

FWIW, my personal approach to Web apps these days is different: single page Web apps (everything static, CDN hosted, or baked into mobile app with Cordova) + “headless” WAMP components. So I don’t have the need for some dynamic HTML generator anymore.

But of course I acknowledge this won’t be for everyone.

I think that’s a common pattern these days, but if WAMP’s principles are based on these premisses, they must be conveyed and documented. Otherwise, you need to make sure various common patterns are supported equally well.

So yes, totally, I think we need better bridging of Crossbar with Django, Flask, etc.

Useful but I can’t tell if it’s up to the crossbar community to provide such support. Or, to those respective communities instead?

I assume, initially Michel highlighted the crossbar project is not enough marketed. He suggested you guys do this via a smoother integration with existing well-known projects. Is that the right path? If you want to market a shift in the way the Python world builds webapps, maybe it’s fine you don’t integrate well with them at all?

0 Likes

#7

Hi Sylvain,

> 5)

    FWIW, my personal approach to Web apps these days is different:
    single page Web apps (everything static, CDN hosted, or baked into
    mobile app with Cordova) + "headless" WAMP components. So I don't
    have the need for some dynamic HTML generator anymore.

    But of course I acknowledge this won't be for everyone.

I think that's a common pattern these days, but if WAMP's principles are
based on these premisses, they must be conveyed and documented.

I think you nailed it.

It's kind of strategic decision: do we want to make a "clear cut" rgd. how Web apps are built, move forward, and clearly communicate that?

Otherwise, you need to make sure various common patterns are supported
equally well.

    So yes, totally, I think we need better bridging of Crossbar with
    Django, Flask, etc.

I've been thinking more about it, and the approach that wouldn't hold us back (and put too much burden on us) is:

A 2-way WAMP/REST bridge:

1)
Having Crossbar be able to forward WAMP calls to HTTP/REST requests ("Callee") and receive HTTP/REST requests making forwarding into WAMP calls ("Caller").

2)
Likewise, have Crossbar forward published WAMP events to HTTP/requests ("Subscriber"), and receive HTTP/REST requests to forward as WAMP events ("Publisher").

This can be done, and would work "generically": anything that can issue and receive HTTP/REST requests would be able to integrate.

Useful but I can't tell if it's up to the crossbar community to provide
such support. Or, to those respective communities instead?

It would be endless work. In particular: there is not only Python, but the NodeJS, Java, PHP and others also. WAMP is deliberately polyglot by design - as much as I love Python, choice/freedom is good.

And with a WAMP/REST bridge, projects could further "sugar up" the REST stuff within their code to make using the bridge more comfortable -- if they like.

I assume, initially Michel highlighted the crossbar project is not
enough marketed. He suggested you guys do this via a smoother

Yes, we have a marketing problem. Not sitting in a SF bay area Web hipster cafe all day long doesn't help I guess;)

integration with existing well-known projects. Is that the right path?

> If you want to market a shift in the way the Python world builds
> webapps, maybe it's fine you don't integrate well with them at all?

Good question.

The REST/WAMP bridge .. I like that. It already provides enough to integrate with established Web projects - on a least common denomiator basis: HTTP/REST

But in the end, there is no way denying how we see things through the WAMP lense: building Web apps by generating HTML is wrong.

We _want_ to shift that.

"""
If you are a Django/Flask/CherryPy developer, you can use the WAMP/REST bridge, but it's a stop gap solution and you should really consider writing your whole app differently.
"""

So the PR question is: how can we communicate and evangelize such a radical departure?

Thanks for your thoughts!

/Tobias

···

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

--
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#8

Javascript had it easy, they had almost no framework, no pattern and a
blank page. On top of that, they always seem to draw people who can design
them modern, sexy websites :slight_smile:
Perhaps, if you want to succeed, you'll have to act like them. The message
is important but the form you deliver it in, usually, is even more
important to really start gathering a momentum.

In any case, I'm happy seeing a new form of designing and building web
application in the Python world. We need a fresh perspective and crossbar
certainly has that potential.

Cheers,

···

On 26 May 2014 12:01, Tobias Oberstein <tobias.o...@gmail.com> wrote:

Hi Sylvain,

> 5)

    FWIW, my personal approach to Web apps these days is different:
    single page Web apps (everything static, CDN hosted, or baked into
    mobile app with Cordova) + "headless" WAMP components. So I don't
    have the need for some dynamic HTML generator anymore.

    But of course I acknowledge this won't be for everyone.

I think that's a common pattern these days, but if WAMP's principles are
based on these premisses, they must be conveyed and documented.

I think you nailed it.

It's kind of strategic decision: do we want to make a "clear cut" rgd. how
Web apps are built, move forward, and clearly communicate that?

Otherwise, you need to make sure various common patterns are supported

equally well.

    So yes, totally, I think we need better bridging of Crossbar with
    Django, Flask, etc.

I've been thinking more about it, and the approach that wouldn't hold us
back (and put too much burden on us) is:

A 2-way WAMP/REST bridge:

1)
Having Crossbar be able to forward WAMP calls to HTTP/REST requests
("Callee") and receive HTTP/REST requests making forwarding into WAMP calls
("Caller").

2)
Likewise, have Crossbar forward published WAMP events to HTTP/requests
("Subscriber"), and receive HTTP/REST requests to forward as WAMP events
("Publisher").

This can be done, and would work "generically": anything that can issue
and receive HTTP/REST requests would be able to integrate.

Useful but I can't tell if it's up to the crossbar community to provide

such support. Or, to those respective communities instead?

It would be endless work. In particular: there is not only Python, but the
NodeJS, Java, PHP and others also. WAMP is deliberately polyglot by design
- as much as I love Python, choice/freedom is good.

And with a WAMP/REST bridge, projects could further "sugar up" the REST
stuff within their code to make using the bridge more comfortable -- if
they like.

I assume, initially Michel highlighted the crossbar project is not

enough marketed. He suggested you guys do this via a smoother

Yes, we have a marketing problem. Not sitting in a SF bay area Web hipster
cafe all day long doesn't help I guess;)

integration with existing well-known projects. Is that the right path?

> If you want to market a shift in the way the Python world builds
> webapps, maybe it's fine you don't integrate well with them at all?

Good question.

The REST/WAMP bridge .. I like that. It already provides enough to
integrate with established Web projects - on a least common denomiator
basis: HTTP/REST

But in the end, there is no way denying how we see things through the WAMP
lense: building Web apps by generating HTML is wrong.

We _want_ to shift that.

"""
If you are a Django/Flask/CherryPy developer, you can use the WAMP/REST
bridge, but it's a stop gap solution and you should really consider writing
your whole app differently.
"""

So the PR question is: how can we communicate and evangelize such a
radical departure?

Thanks for your thoughts!

/Tobias

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

0 Likes

#9

What I think is the biggest adoption issue, however, is the API.
Autobahn should have a small cost of entry, and right now it doesnt. The
hello world is not only hard to write using the documentation, but quite
scary :

Alright, here is working code

https://github.com/tavendo/AutobahnPython/blob/app_wrapper/examples/twisted/wamp/app/hello.py

This exposes a procedure to be called via WAMP from any WAMP caller (JS, C++, Python, ..).

FWIW, it now looks very similar, and has same number of code lines as "hello world" with Flask

http://flask.pocoo.org/

Note: this is _experimental_. It's incomplete and we need to hash out more. But it's a start.

If you feel to comment/discuss, yes please! Also here

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

Cheers,
/Tobias

0 Likes

#10

snip

Javascript had it easy, they had almost no framework, no pattern and a
blank page. On top of that, they always seem to draw people who can
design them modern, sexy websites :slight_smile:

That's true.

Any Web designers out there who wanna help?

Perhaps, if you want to succeed, you'll have to act like them. The
message is important but the form you deliver it in, usually, is even
more important to really start gathering a momentum.

Yeah, it's just more fun to look at nicely designed things ..

In any case, I'm happy seeing a new form of designing and building web
application in the Python world. We need a fresh perspective and
crossbar certainly has that potential.

Great;)

And not only Web, but also embedded/IoT in particular. We're getting a lot of feedback from there .. e.g. the most visited single page overall is

http://tavendo.com/blog/post/arduino-yun-with-autobahn/

which draws roughly 100 visitors per day.

And we shouldn't forget C++, Android, Node developers as well ..

Cheers,
/Tobias

0 Likes

#11

And WAMP works so wonderfully well with Node.js so we can use Javascript + WAMP on the client and the server.

I’m also just finishing a Web Browser Extension which is also using WAMP to talk to the Node.js server and it is working a treat.

···

On Mon, May 26, 2014 at 10:55 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

snip

Javascript had it easy, they had almost no framework, no pattern and a

blank page. On top of that, they always seem to draw people who can

design them modern, sexy websites :slight_smile:

That’s true.

Any Web designers out there who wanna help?

Perhaps, if you want to succeed, you’ll have to act like them. The

message is important but the form you deliver it in, usually, is even

more important to really start gathering a momentum.

Yeah, it’s just more fun to look at nicely designed things …

In any case, I’m happy seeing a new form of designing and building web

application in the Python world. We need a fresh perspective and

crossbar certainly has that potential.

Great;)

And not only Web, but also embedded/IoT in particular. We’re getting a lot of feedback from there … e.g. the most visited single page overall is

http://tavendo.com/blog/post/arduino-yun-with-autobahn/

which draws roughly 100 visitors per day.

And we shouldn’t forget C++, Android, Node developers as well …

Cheers,

/Tobias

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+unsubscribe@googlegroups.com.

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


Neville Franks, Author of Clibu, a better way to collect, use, manage and share information.

Soft As It Gets Pty Ltd

0 Likes

#12

And WAMP works so wonderfully well with Node.js so we can use Javascript
+ WAMP on the client and the server.

Yeah! As much as I love Python, WAMP (and Crossbar) should really be agnostic / polyglot - and it is. JS, C++, Java, X, Y -- should be a developer choice, not imposed by a "messaging substrate" like WAMP ..

···

Am 26.05.2014 22:45, schrieb Neville Franks:

I'm also just finishing a Web Browser Extension which is also using WAMP
to talk to the Node.js server and it is working a treat.

On Mon, May 26, 2014 at 10:55 PM, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:

    snip

        Javascript had it easy, they had almost no framework, no pattern
        and a
        blank page. On top of that, they always seem to draw people who can
        design them modern, sexy websites :slight_smile:

    That's true.

    Any Web designers out there who wanna help?

        Perhaps, if you want to succeed, you'll have to act like them. The
        message is important but the form you deliver it in, usually, is
        even
        more important to really start gathering a momentum.

    Yeah, it's just more fun to look at nicely designed things ..

        In any case, I'm happy seeing a new form of designing and
        building web
        application in the Python world. We need a fresh perspective and
        crossbar certainly has that potential.

    Great;)

    And not only Web, but also embedded/IoT in particular. We're getting
    a lot of feedback from there .. e.g. the most visited single page
    overall is

    http://tavendo.com/blog/post/__arduino-yun-with-autobahn/
    <http://tavendo.com/blog/post/arduino-yun-with-autobahn/>

    which draws roughly 100 visitors per day.

    And we shouldn't forget C++, Android, Node developers as well ..

    Cheers,
    /Tobias

    --
    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+unsubscribe@__googlegroups.com
    <mailto:autobahnws%2...@googlegroups.com>.
    For more options, visit https://groups.google.com/d/__optout
    <https://groups.google.com/d/optout>.

--
Neville Franks, Author of Clibu <http://www.clibu.com>, /a better way to
collect, use, manage and share information./
  Soft As It Gets Pty Ltd

--
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes