The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I think it got that reputation on account of being the first widely adopted extensible textual structured data format online. It was really the idea of such a format that was a fix all rather than Xml itself, if anything. just my $0.02
RPCs are generally for people who couldn't be bothered to write state machines. Which means that they're usually execrable. They're why a little spinning wheel appears on the screen and you can sit there and stare at it until the cows come home or it has the courtesy to time out. Utter dross.
What you're missing is the internet. This is a client server scenario. At some point the client needs to fetch data from the server.
It has nothing to do with async and everything to do with the basic problem of communicating across a network boundary.
I feel like we're talking about two totally different things. Remote procedure calls - a way to call a method across a network boundary.
Maybe we are talking about two different things. To me, an RPC (so named because it behaves as if you called a procedure that returned a result) is a blocking send. Synchronous messaging. The send function waits for the result to arrive, causing the thread to be scheduled out.
The usual meaning of RPC is that the client blocks until the server responds. Getting back a token that is later used to retrieve the result doesn't make it look like a regular procedure call. But it's a much better way to do it.
I'm glad to hear it, because I was frustrated when I wrote it, and I can tell by reading it, but I wasn't frustrated at you. =)
Basically the browser is creating your state machine for you if you just <script> to an url (or any of the other enumerable ways to get JS to load something asynchronously)
Adding: with JS you wouldn't use a cancelation token, but rather a callback method ala JSONP to do your async notify. In JS this is cake as all functions are basically delegate objects
I route responses to asynchronous requests just like other messages: received by an I/O thread, put on a work queue, and eventually dequeued by an "invoker thread", so named because it invokes applications to pass them messages. I find that there are advantages to having a consistent flow of control.
I mean, this is basically what that cooperative fiber stuff is doing behind the scenes. It's got a message pump. It's just that JS, being a scripting language, does it for you and hides the grotty details.
The upshot is you don't have script kids blowing up multithreaded code.
The downside is you don't have any more control than what you can convince JS to give you.
But overall, it's a good model considering the audience. Makes async painless, and it's actually almost easier to do async than sync calls with JS.
It's weird how to do it, but yes, in at least half the cases it's easier to do async than sync
My boss keeps talking about Python having "support" for JSON as well.
I definitely do not need to have a million "objects" all in memory at once.
All I do is kinda stream it into SQL Server as quickly as I can.
Plus, I can't simply go downloading stuff and installing it, and it would likely take at least a year for the "security" weenies to approve a package.
So, I roll my own. Now I have an importer utility which can read XML, JSON, or "CSV" -- convert to XML as necessary -- and write to SQL Server in a number of ways.