Why is the call result transmitted by invoking a callback?

Because if the call is very long, it will block the wsgi process. If you call an external service to encode a video, you don’t want to wait for the whole video to be encoded to process the next HTTP request.

One problem: when a WAMP client that has registered/subscribed just dies, the router will notice and automatically unregister/unsubscribe.

No solution is perfect, if people want a perfect fit, they shall use autobahn :)

first, I think your list of blockers to WAMP adoption nails it. We simply need to get much better on these issues.

Rgd 4):

The “publisher” role of such a bridge is already implemented:

https://github.com/crossbario/crossbar/wiki/HTTP%20Pusher%20Service

This can be used to publish WAMP real-time events from plain Django or whatevers apps. It also supports “signed” requests.

It differs in 2 aspects from the proposal above: a) the WAMP topic is in the POST body (and hence will be signed too with signed requests), and b) the signing works with a simple, secure scheme, not JSON token

Rgd. 3):

Why is the call result transmitted by invoking a callback? Why not simply return the result as part of the initial HTTP/POST?

That would essentially make the bridge API of 3) very similar to 4).

===

Rgd. 1) + 2) – that is REGISTER and SUBSCRIBE.

Yes, here we need definitely REST callbacks.

One problem: when a WAMP client that has registered/subscribed just dies, the router will notice and automatically unregister/unsubscribe.

When a legacy app using the REST bridge dies, this will not be noticed by the router. It will only be noticed when the router would try to invoke a REST callback on the legacy app to invoke a procedure or deliver an event.

En attendant l’article sur S&M, faire un tour sur wikipedia c’est déjà pas mal :).

Merci pour la précision. J’ai des choses à apprendre, c’est bien.

Salut et merci pour toutes ces infos sur WAMP. La stack à l’air bien cool. Toutefois, un truc me chiffonne, c’est que ça repose sur > websocket qui propose en gros de faire de la communication “temps réel” sur HTTP qui fonctionne en requête / réponse.

Websocket n’est pas HTTP

C’est un protocole distinct, fait pour le temps réel. Il va falloir que je fasse un article là dessus car je m’aperçois que beaucoup de gens ne savent pas ce qu’est Websocket. C’est dommage car c’est une très belle techno. Si on a la possibilité de l’utiliser (IE10 ou plus ou un shym flash), il ne faut pas hésiter. C’est beaucoup plus rapide, léger et efficace qu’AJAX car ça ne marche pas du tout pareil.

Alors, effectivement, c’est sympa de pousser des notifications au browser mais y a-t-il une réel plus value à généraliser pour tout ce qui > est communication inter process ? Est-ce qu’on n’a pas tendance à se servir d’HTTP pour tout alors qu’il y a peut-être des protocoles plus mûrs / stables (je pense à AMQP ?).

Websocket est fait pour ça. Ce n’est pas un hack, un détournement de la techno. C’est fait exprès pour une fois pour toute casser cette distinction communication client/server/process qui n’a lieu d’être qu’à cause des barrières technologiques.

Je me réponds (partiellement) : la plus value est de brancher directement le browser sur une file de message sans passé par un serveur intermédiaire ce qui va bien dans le sens de micro service.

On passe bien par un serveur intermédiaire. WAMP à besoin d’un routeur. Si tu veux du P2P, il faut utiliser WebRTC. Mais même là il y a un serveur pour le signaling. Le vrai P2P, c’est malheureusement pas pour demain. D’ailleurs, ça me fait bien chier que les browsers intègres par le protocole torrent par défaut. Il a fait ses preuves.

Donc dans le premier frein à l’adoption, ce que je vois c’est le sentiment d’avoir une nouvelle technos pour la communication entre processus en plus des zillons de solutions existantes, qui plus est basée sur HTTP qui n’est pas forcément pensé pour à la base.

A toi de de me dire si je dis de la merde ou pas :)

Je le formulerai pas ainsi. Disons que ça mérite une complément d’informations ^^ Je vais écrire ça demain.

Je me réponds (partiellement) : la plus value est de brancher directement le browser sur une file de message sans passé par un serveur intermédiaire ce qui va bien dans le sens de micro service.

Donc dans le premier frein à l’adoption, ce que je vois c’est le sentiment d’avoir une nouvelle technos pour la communication entre processus en plus des zillons de solutions existantes, qui plus est basée sur HTTP qui n’est pas forcément pensé pour à la base.

A toi de de me dire si je dis de la merde ou pas :)