Reviewing SignalR–Part I
After reading this post from Scott Hanselman, I decided that I really want to take a look at SignalR.
There aren’t any docs beyond a few code snippets, so I created a new project and downloaded the nuget version, and started exploring the API in Object Browser. My intent was to write a small sample application to see how it works. But I run into a road block very rapidly:
Huh?!
Why on earth would it return dynamic for the list of clients. That seems highly suspicious design decision, and then I looked at this:
Hm… combine that with code snippets like this (from Scott’s post):
If it was someone else, I would put that receive call down to someone who doesn’t know/care about the design guidelines and just didn’t name the method right. But I assume that Scott does, so it is probably something else.
What seems to be happening here is that the Hub is indeed a very high level API, it allows you to directly invoke the JS API on the client. This is still unconfirmed as of yet, but it seems reasonable from the code I have so far, I intend to go deeper into the SignalR codebase and look for further details, look for a few posts on the topic.
Comments
That's David Fowler and Damian Edwards' decisions, far be it from me to take credit for their good works.
But, yes, it's a high level API that lets you directly call client-side JavaScript from the server-side, based on both sides having the same method name. You could have called received "poo" and then clients.poo if you like. It's using unknown methods as a dispatching mechanism.
lol @ poo
Comment preview