Hi Tobias, Greg,
Tobias, I've now been fiddling around with crossbar and it's going to replace my router. Up to this point it does exactly what I need. But I still think that there should be a way for frontends to get notified about disconnects from backends.
Maybe the best way would be to allow frontends (or AppSessions in general) to register to RPC method avaliability notifications. For example if a backend implements an com.myapp.hello RPC method, then a frontend can tell the router that it should get notified when the backend implementing this method joins / leaves the router. Even if crossbar could implement this, it's a basic enough feature to justify its existence in the basicrouter / WAMP BP. A backend or frontend could add a flag to a RPC method it implements, to optionally enable realtime avaliability information about that method in the system.
On a system I built on WAMP v1 I also dealt with routing. All clients would register to the router by telling the router which tags the clients subscribes to. Then, endpoints would publish all to the same topic specifying a message, category and tag, where tag would allow the router to filter out clients which didn't subscribe to them, category would ease clients to select the action to perform on the message or the extra data associated with the message. These do also get stored in the database.
Basically a database entry looks like
/* 46 */
{
"_id" : ObjectId("541276c8cf1e8c0c6c63e818"),
"category" : "notification/message",
"status" : "ok",
"uuid" : "752eda40-3a35-11e4-aabf-00012e2fc013",
"tags" : ["dev"], // <============================= only to developer devices
"when" : ISODate("2014-09-12T04:30:00.163Z"),
"message" : "Licht Wohnzimmer Katrin 80->1024",
"options" : {
"hidden" : false,
"store" : true
}
}
/* 68 */
{
"_id" : ObjectId("5412f623cf1e8c0c6c63e82e"),
"category" : "phone/call",
"status" : "ok",
"uuid" : "5e6b4cc0-3a81-11e4-9247-00012e2fc013",
"tags" : ["all"], // <============================= to every device
"when" : ISODate("2014-09-12T13:33:23.723Z"),
"message" : "Armin XXXXXXXX (Seba) → K'",
"options" : {
"direction" : "in",
"uuid" : "2014-09-12T13:33:22.351+0000",
"tts" : true,
"say" : "Armin XXXXXXXX (Seba) für Katrin",
"action" : "request",
"store" : true
}
}
/* 70 */
{
"_id" : ObjectId("5412f696cf1e8c0c6c63e830"),
"category" : "phone/call",
"status" : "ok", // <============================= to every device
"uuid" : "a2886f00-3a81-11e4-9d39-00012e2fc013",
"tags" : ["all"],
"when" : ISODate("2014-09-12T13:35:17.998Z"),
"message" : "Armin XXXXXXXX (Seba) → K'",
"options" : {
"direction" : "in",
"uuid" : "2014-09-12T13:33:22.351+0000",
"duration_pretty" : "1m 36s",
"extension_short" : "KDCT",
"action" : "disconnect",
"duration" : 96.844009,
"store" : true
}
}
Keep in mind that these messages belong to a messaging system, not to a control system, they are just intended to deliver text notifications to endpoints, where the notifications can be enriched with additional information. For example the SBC's for home lighting post such a message to this system, or the telephony system. They can do this easily since the router has an integrated web server so that
http://router.example.com/publish?message=Licht Wohnzimmer Katrin 80->1024&category=notification/message&tags=dev&options=... results in such a message. They can be optionally stored in the database so that web pages can query the database to get a history of the notifications.
In another app I was doing I focused on the tag-subscription mechanism which is where this topic got handled
http://stackoverflow.com/questions/10281863/in-python-how-can-i-query-a-list-of-words-to-match-a-certain-query-criteria so that tags could contain hierarchical structures ( level1/level2/level3, like home/lighting/livingroom ), and publishers could use levels to select the ganularity of who is a recipient (ie users/kids/* vs users/kids/seba) even use regular expressions to select the targets: (users/kids/* dev.* where dev.* is a regex while users/kids/* is a wildcard). I will check this out again after I have a better understanding of crossbar. BTW this was part of a test system which also contained reflection, where components which registered at the router would announce all the mentods they have avaliable, including their parameters, and the configuration state (variables) of the component, as well as avaliable configuration sets (ie ping every 10 seconds to tag=dev or every 30 seconds to tag=all, or a realtime stock tracking component where stocks=fb or stocks=fb,goog,amz). Frontends are able to shutdown/spawn backends and load configurations. See the attached image. It starts with a client/html, which is the page, there's a system/chat backend registered at the router, which would post messages to everyone subscribed to teh tag "chat" (taargets: chat). Then there's a service/stock backend, to which client/html registers at 17:31:11.237. Tags can be denied access to if other tags are not present, which is a very rudimentary access control. This is a lot of info, I hope I find time to reuse and share this system.