I’m working on a collaborative document editing application where clients can open up a document, post edits via a webservice, and subscribe to updates made to the document using SignalR. I’m experimenting with my SignalR setup and can’t quite get what I want.
My gut tells me that I should shoot for a setup where each document has an endpoint with a name like “subscribe”, so the full path would be “/documents/1/subscribe” for document 1 and “/documents/2/subscribe” for document 2. However, as far as I can tell, SignalR wants me to have a single endpoint, and then manage which clients get updates either by using Groups or by managing the list of subscribers for a document in code myself and send out individual messages.
As a result I have two questions.
- Is there a way to do what I want to do what I want to do with SignalR?
- Is there a reason what I want to do is totally wrong headed and silly?
Aside from “dedicated”, friendly looking URLs I don’t really see any value to this vs. just using groups. In fact, the only thing I could see it doing is adding more overhead because of the way the message bus internals of SignalR work with respect to scale.
If you did want to try this, the base thing you’d need to figure out would be registering routes on the fly per document, which, as Phil Haack’s RouteMagic has done for MVC, I suppose it might be possible for SignalR route configurations as well.