Looks like it soon might be time for another beer…! ;^)
- “Prefix”-based subscriptions - being able to subscribe to topic
“a.b.c” and automatically receive events published to topics like
“a.b.c.d”, “a.b.c.d.e”, etc.
The feature is clearly defined and will be implemented soon in Crossbar.io
Awesome - thank you! Can’t wait.
“Reflection” is not yet fully defined/designed, but we will have
something here soon too. Within Crossbar.io, we already have
which will be the basis to implement such meta services.
Again, terrific. Again, can’t wait. :^)
- Some kind of discovery/registration mechanism by endpoints with the
router. This might better be a function of the application, not the
router/WAMP protocol itself. I think I did see some sort of discussion
elsewhere in the forum here about this idea but now I can’t find it.
Service registration/dicovery/activation: this area is still in
“contemplating” / collecting ideas phase.
My gut tells me: this is important piece of the puzzle, but we might
need to gain more experience first with real-world scenarios to come up
with something robust.
If you want, you can help:
collect the infos, comments, opinions etc touching this topic from the
mailing list, plus the issues on the WAMP repo probably by linking from
a new Wiki page
Also add pointers to previous art (like what did the SOA guys do) etc.
Then try to distill it into some coherent design / thinking on that Wiki
I would love to if I can find time; I will see if I can. This concept seems fundamental to what we want to accomplish with our IoT devices coming online and automatically connecting to/registering with a centralized router. The reason I wonder if maybe it should remain an application config issue is that we want our IoT to be a WAMP client to the centralized router, yet host its own WAMP router to serve its own information to other clients. They’re related ideas, but seem like they should remain separate. Maybe there could be some kind of optional WAMP client configuration issue, where it requests to be discovered, and an optional WAMP (advanced) router feature to listen/receive that discovery request, and connect the client, etc.
Can I also ask a question about WAMP topics? We are thinking of
designing things such that a particular RPC call would 1) input a
command into our IoT device, and 2) create/subscribe to a new topic so
that the command initiating client could receive notifications about the
progress of the command. My question is, if we were to create a unique
FWIW, you don’t need ephemeral/throw-away topics to report progress on
WAMP AP (and Crossbar.io) has progressive results:
This may be the best answer of all, since it’s already implemented and will be needed for just about every RPC call we will implement in our IoT device. When a client makes the RPC request, the receiving WAMP component has to interact with the rest of the IoT device system to deliver the request. This “progress” architecture seems ideal.
topic for each command, does the router internally clean up of the
(aged) topics once no one is (explicitly) subscribed to them? I’m simply
Yes, Crossbar.io does clean up data structures when the last subscriber
on some topic unsubs/leaves.
In general, this is a valid concern: memory leaks / months of uptime. I
do think we have a solid code base. But that’s just opinion. FWIW, we
are currently preparing a performance/stability test set for Crossbar.io
- mainly to get ready for adding clustering to the routing core.
Honestly, I’ve really been nothing but impressed with Crossbar - both with what it already has (and its stability) and its potential!
Thanks as always for all the good information. Is there a mailing list to be able to get notified whenever new releases of Crossbar and Autobahn are available?
On Tuesday, December 30, 2014 4:36:38 AM UTC-5, Tobias Oberstein wrote: