|
Is. Was means 'back in the days when everyone used it a lot'. Even VB6 still exists, although it's a lot less useful than XML, which I am sure is still used.
|
|
|
|
|
I use XPath nearly every day. Very handy in a tight spot.
|
|
|
|
|
Yeah, I'm sure some people still do. Nothing wrong with that, it's hardly outdated. XML is just not the fix all it was assumed to be in 2002
|
|
|
|
|
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
hack everything.
|
|
|
|
|
I'm not even talking about xpath. JSONPath does the same thing, except through JSON documents.
The *only* reason JSONPath is simpler is because JSON *structure* is simpler (no attributes, no namespaces, all keys are fixed to field names instead of based on the key marker in an XSD schema)
Yes, *XML* is fundamentally more "powerful" than JSON because it can represent more data in more ways. It's more expressive.
However, it's also clunky if all you need is something basic like JSON provides.
hack everything.
|
|
|
|
|
I can't help but jump into a gabfest!
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.
|
|
|
|
|
there are valid reasons for json RPCs though, like querying a large database at a foreign entity.
Better to do that than to refresh the whole page
hack everything.
|
|
|
|
|
Maybe I'm missing something, but I don't see why this kind of thing can't be done asynchronously.
I see RPCs as anathema because they lead to gross inefficiencies and undesirable attributes:
- in a server, large thread pools (e.g. Thread Per User or Thread Per Request)
- the inability to handle other inputs (e.g. client cancellations--the "spinning wheel on the screen" problem)
- the inability to send parallel requests because RPCs block
- responses and timeouts arriving inside application functions instead of being routed top-down like other inputs
- in some implementations, undesirable coupling caused by explicitly naming the destination function
I've seen systems where mutexes were held during RPCs. This really does wonders for latency.
RPCs are good for prototyping but shouldn't appear in production code.
|
|
|
|
|
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.
hack everything.
|
|
|
|
|
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.
|
|
|
|
|
RPC calls can indeed be asynchronous.
I'm not sure who told you otherwise.
Synchronous messaging is just a standard way to do the baseline, just like a single threaded app is a standard baseline way to write one, but an app by definition isn't single threaded.
When you do asynchronous RPC you make the call, and you get something like a return/cancellation token you can use to retrieve your result later.
Doing RPC over HTTP can be async, you just use request/response for the request, and then request/response again for the response (or hack the http result using keep alive and spit that way)
hack everything.
|
|
|
|
|
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.
|
|
|
|
|
yeah, it's a basic pattern in doing asynchronous programming.
Seriously, there's nothing fundamentally synchronous about RPC.
That's why it's not called SRPC.
That's why there's no ARPC
It's just RPC
Remote
Procedure
Call
Nothing in there about sychronicity
Sorry I realized afterward how much of a jerk i just sounded like.
Life stuff was frustrating me, it wasn't you.
I'm in need of a cigarette i can't have.
hack everything.
|
|
|
|
|
No need to apologize. I don't think you sounded like a jerk.
|
|
|
|
|
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. =)
One of the nice things about JS is it's really easy to set it up to do asynchronous RPC. Creating a "thread" in javascript (not a real thread) is easy as pie, and since it's not a real thread, but rather a cooperatively scheduled fiber spawned by the browser you don't need to work synchronization primitives.
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
hack everything.
|
|
|
|
|
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.
hack everything.
|
|
|
|
|
If it's easier to do asynch than synch, it definitely has my vote of approval!
|
|
|
|
|
It's weird how to do it, but yes, in at least half the cases it's easier to do async than sync
Javascript is a strange animal, especially when using it this way and "threading" using the browser's dom elements like script blocks. It's a total hackfest, like most of javascript, but once you get the model down, if you abstract it then using it is lovely.
hack everything.
|
|
|
|
|
My boss keeps talking about Python having "support" for JSON as well.
But I don't need "support" (and I don't touch Javascript (ptui)).
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.
Edit:
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.
modified 9-Jan-20 19:03pm.
|
|
|
|
|
that works.
Your boss is silly. Pretty much every turing complete language has "JSON support" but Javascript is the only one where JSON objects are truly "first class" objects and not behind a facade.
hack everything.
|
|
|
|
|
honey the codewitch wrote: are truly "first class" objects
Which I don't need. At all.
|
|
|
|
|
it's nice when you're trying to RPC from inside a browser though!
hack everything.
|
|
|
|
|
I write backend database stuff.
At times calling RESTfull services and such to get data and load it into staging. Being able to consume JSON is very helpful.
|
|
|
|
|
Hmm, so there's nothing stopping me from implementing a JSON parser in XSLT...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
