On Fri, Mar 30, 2012 at 23:10, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:
Am 30.03.2012 22:52, schrieb Daniel F.:
btw, are those URI topics mandatory? Basically they would replace my
tags, or extend them, like you show in your example. I don't
the benefit of this.
The benefits of using URIs (from the HTTP scheme) are:
* well known hierarchical naming scheme
* an established global name registry / arbitration system (DNS)
* by virtue of the first two, ability to integrate apps from
different vendors without naming conflicts
* as a potential feature in the future: have the ability to make those
URIs derefencable for obtaining metadata
URIs are mandatory for topic and procedures. The current AutobahnXX
implementations don't _yet_ enforce this, but will do so.
In your payloads (RPC args, PubSub event payload) you are free do
to anything of course.
We for our apps use URIs for anything which isn't a literal value,
that is all ID like things, vocabulary (verbs, adj, ..) describing
relations between entities .. everything.
On Friday, March 30, 2012 10:50:01 PM UTC+2, Daniel F. wrote:
I somehow have an aversion to pubsub, which is probably due
lack of insight to it. Is it possible to use rpc and pubsub
same port and interface? Currently I'm settled with the idea
publishers communicating on one port and subscribers on
when only using pubsub, I guess that this makes them both
same port. But what about authentication with rpc, would
on the same port, even on the same connection, so that I can
authenticate with rpc and then when all is ok use pubsub without
building a new connection?
On Friday, March 30, 2012 9:24:30 PM UTC+2, Tobias Oberstein > wrote:
Autobahn's PubSub system _is_ a message broker.
You can have clients subscribe to one or more topics like
and have data source publish to those topics.
The broker (Autobahn PubSub) does the lifting of maintaining
subscriptions and dispatching messages accordingly.
On that level, the message dispatching logic is purely based
on topic URI.
If you need more flexibility, i.e. content-based dispatching
(like if call_duration < 10, then only publish to
if call_duration >= 10, then publish to client2) you can
have custom publish (and also subscribe) handlers.
Autobahn does have TLS .. for WS and for WAMP.
For authentication of clients and data sources, you can use
WAMP RPC ..
It's really the scenario for which WAMP is suitable .. WS is
too low level, but don't reinvent the wheel for each new
Am 30.03.2012 20:21, schrieb Daniel F.:
> now that hixie has been incorporated into Autobahn, I'm about to
> rewrite some parts of a system. Currently I'm only using a
> broadcast_server type of functionality, but I'd like to know
> missing out on something by not using pubsub.
> My system contains a couple of data sources. These are a
> which notifies of incoming and outgoing phone calls, email
> which notify when emails arrive or get deleted, an
> notification system, among others. All these data sources use
> categories to label the data, for example phone/incoming,
> or reminder/notify. The data sources also do set tags to whom
> data is targeted at, ie "all", "tablet", "user1", and so on.
> The system also contains data consumers, which log into the
> broker and provide it with tags to indicate the type of
> are, ie "tablet,android,user1"
> So the phone system may send a "Incoming call from XYZ" message,
> categorized with phone/incoming, targeted at "user1" to the
> broker, and the message broker, which is the
> it to all devices which told the broker that they where
> data tagged with "user1".
> The consumers then use the category to decide what to do with the
> message. So a browser would popup a div showing a phone icon
> name of the callee and to whom it is destined to, or it would
> via tts, or play a sound to indicate that the answering machine
> answered the phone. A tablet on the other hand would would
> widget with the event and so on.
> It's a very simple system, that's the good thing about it, so
> sure if I really have any benefit from using pubsub or rpc.
> The message broker lives inside a cherrypy web server, so the
> sources make a url call to the web server notifying it that
> new event, and the server uses the message broker which
> message to the clients, which are connected via websocket.
> I want to take the message broker out of the web server, and
> the data sources to use Autobahn's rpc system to push
messages to the
> broker, which then hands over the message to the devices. Is
> much overhead? Currently everything works with urlopen, and
> the encoding annoyances, it seems to be a lightweight and
> to trigger the broker to distribute messages. Are there
> using Autobahn's rpc in every data source and the broker? Or
> use pubsub? I plan to extend the message broker to include tls,
> authentication for data sources and sinks (devices), so what
> think, which would be the best approach to rebuild this part
> system? I'm definitely planning on using Autobahn, as the
tech got me
> completely convinced, I'm just not sure about which features
> Kind regards,