Slashdot Mirror
What is JSON, JSON-RPC and JSON-RPC-Java?
Michael Clark writes "Seen those funky remote scripting techniques employed by Orkut, Gmail and Google Suggests that avoid that oh so 80's page reloading (think IBM 3270 only slower). A fledgling standard is developing to allow this new breed of fast and highly dynamic web applications to flourish.
JSON (JavaScript Object Notation) is a lightweight data-interchange format with language bindings for C, C++, C#, Java, JavaScript, Perl, TCL and others. It is derived from JavaScript and it has similar expresive capabilities to XML. Perfect for the web as doesn't suffer from XML's bloat and is custom made for our defacto browser language.
JSON-RPC is a simple remote procedure call protocol similar to XML-RPC although it uses the lightweight JSON format instead of XML (so it is much faster).
The XMLHttpRequest object (or MSXML ActiveX in the case of Internet Explorer) is used in the browser to call remote methods on the server without the need for reloading the page.
JSON-RPC-Java is a Java implementation of the JSON-RPC protocol.
JSON-RPC-Java combines these all together to create an amazingly and simple way of developing these highly interactive type of enterprise java applications with JavaScript DHTML web front-ends.
" Click below to read more about it.
"Now is the turning point. Forget that horid wait while 100K of HTML downloads when the application just wanted to update one field on the page.
The XMLHttpRequest object has made it's way into all the main browsers with it's recent introduction into Opera and Konqueror (sans the Konqueror bug).
This new form of web development now works on Internet Explorer 5, 5.5, 6, Mozilla, Firefox, Safari 1.2, Opera 8 Beta and Konqueror 3.3 (with a much needed patch).
Appeal to Konqueror users - please log into the KDE bugzilla and vote on this bug
so you to can experience this wonderful thing.
More details here: http://oss.metaparadigm.com/jsonrpc/ "
*finishes reading summary*
ok... so... huh?
Two major issues that come to mind with this type of technology:
1) How easy is it to learn for the average programmer
2) What kind of security precautions can we expect to see?
Otherwise it sounds like a great technology to use for web developers who wish to have dynamic content on their sites.
And they said zombies weren't real!
You know, guys, there's a reason that we have separate application programs instead of doing everything through Internet Explorer. Believe it or not, it's not necessarily the best interface for a lot of things.
With all that stuff going on it's a wonder it didn't click itself!
I've had to resort to all sorts of tricks to avoid postbacks in my current (aspx) development efforts. First we used a thrid party soap-xml RPC like this thing. Then we switched to an IFrame for the postback portion. Then I noticed that MS is including their own new and improved soap-xml RPC thing in .Net 2. Now I read about this.
Seems it is a problem a lot of people need/want to solve - but to be honest, I am tired of having so many different solutions to a problem I should not have to begin with. Isn't there something that can be done with the HTML standard to elliminate the need? Life would be so much better down that path.
slashdot troll = you make a compelling argument I do not like the implications of.
If you want to interoperate with PHP, I'd suggest Harry Fuecks JPSPAN as it is quite nice at hooking javascript up with serverside php
As for xmlhttprequest, it's rather easy to make neato web applications with it. Here's something I coded up the other night (only seems to work in firefox at the moment though): http://www.james-carr.org/index.php?p=8
Cheers,
James Carr
Example in JSON:
The same thing in XML:
Perfect for the web as doesn't suffer from XML's bloat and is custom made for our defacto browser language.
Take a look at those examples and try to explain how is JSON free from bloat when in fact it is even more bloated and slightly more difficult to read and write by humans? It's just another notation with no obvious advantages.
and slow torutring pain for developers.
The user benefit will come from more usable dynamic web applications when this is applied well. The users will suffer when everbody decides their pages need this even when they don't. Kiss that CPU goodbye. The users will get to suffer when they decide to use a platform that didn't rank high enough for the sites QA team to bother checking.
When used and tested well, this can provide some awesome benefits. Hopefully, we'll see more than simple ad/news/stock tickers. Imagine a wiki where several people can edit the same page at the same time, a list of users editing on the side, and a diff color cursor for each user. We could get live spell checking on a web based email client, in a wiki edit window.
Developers, our lives have just become hell. Now PHB's will want this technology to be used everywhere. And its gonna have to work the same on every platform. Browser bugs, browser inconsistencies, oh my....
----- If communism is a system where the government owns business, what do you call a system where business owns govern
It may even not be the better interface for some things, but it *is* the better way to deploy the things. It is specially better if you have to deploy thousands of copies.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
When will the average programmer be able to keep up? I am sure in India they are already teaching classes on this ;-)
Because XML requires a parser, and this JSON thing looks (at least to my very rusty eyes, it's been ages and ages since I touched front-end stuff like javascript) like it could be evaled into a jscript array, which is a *much* quicker operation and requries no external libraries to operate. I've done something like this before, working at a startup back in 2000, with an invisible iframe (we were targeting IE only) that was running jscript which would poll the server api for various things and eval the jscript-formatted output to display stuff (kind of like proto-web-services before such a thing was popular). It sounds kludgy as hell, and parts of it were, but it did work suprisingly well for most of the things we asked it to do. The front-end people had written, I swear to god, a complete windowing/GUI library in dhtml with draggable, resizeable windows (not popups) and everything that our (suite of) ASP-paradigmed applications were flown into.
News for Geeks in Austin, TX
We've written a client for the Remedy Action Request System using JS and the XMLHttpRequest object, with a Java based back end. The client is faster than we ever imagined, and is twice as fast as Remedy's own client. So if you fancy seeing some Shockwave movies of a overly complex web client, which demonstrates exactly what can be achieved with the XMLHttpRequest object, visit: http://www.symbiontsolutions.com/tour Stan
I hope I wasn't the only one that shuddered when I read "remote scripting techniques".
... Yet another standard that can confuse just about everyone. "You have a problem on the server, wait thats written in JSON, we only do XML. The JSON developer is on vacation."
This is a server side push framework based on the same idea. It preceded GMail et alia.
[% slash_sig_val.text %]
All JSON does is make it easier to have your JavaScript call in to your application and parse the results. If you're just interested in presentation, just have your JS call up, get some HTML, and replace the affected HTML. This decreases the amount of JS and increases your re-use (since you don't need to build your UI twice: once is (PHP|Java|.Net|Ruby|.*), and once in JS). You just call your (\1) code on the server from the JS and have it generate the HTML.
I understand that sometimes there are advantages to the programmatic approach that JSON (and XML-RPC, which the browsers support) extoll, but I don't think many developers even realize the UI-based alternative.
"think IBM 3270 only slower"
Hey, 3270s were coax-connected to a channel-attached controller with a 4.5MB/sec path to the CPU. You could do video on them (if you didn't mind the fact that your pixels were the size of a tic-tac.
A.
(who lusts for the feel of a 3270 keyboard under his fingers)
...bringing you cynical quips since 1998
You missed the part that "XML-RPC sucks".
Duct tape, XML, democracy: Not doing the job? Use more.
Because XML requires a parser, and this JSON thing looks like it could be evaled into a jscript array,
Which magical browser do you use that doesn't need to parse the code that it eval()s?
which is a *much* quicker operation
I think that you have forgotten that eval() needs to parse too, I'm not convinced that it is much quicker. Even if it was, it doesn't follow the Principle of Least Power. XML doesn't execute. Javascript does. There's a reason why JSSS was rejected by the W3C and CSS wasn't. Using a fully-fledged scripting language to represent data is insane, especially when you are working with untrusted data off the web.
and requries no external libraries to operate.
An XML parser is built into every web browser that JSON targets.
Yes, mainframes are really, really good at I/O, which is a concept that many people didn't get (DEC for one, when they fell flat on their faces trying to leverage the VAX into mainframe land) and still don't get. The CDC 7600 was surrounded by 6600's to spoon feed it, just as IBM mainframes have channel controllers (real processors) separate from the CPU to do the same thing.
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as it did at our shop multiple times per day? And maybe you could pump bits at it pretty fast, but under TSO your Q1 response time was 10 to 20 seconds during peak times, so it didn't really matter how high-speed the intrinsic channel was.
3270's were designed for forms entry with CICS apps, basically. It's a record-oriented device (like all IBM devices) which just doesn't add up to a very good user experience. You need character interrupts, and you need fast service for those interrupts. The mainframe secret is to let the CPU compute uninterrupted by batching up terminal I/O, screw the user.
Which is exactly the Web experience today. Fill in a form, press a button, wait. Back to the future! In the limit, it doesn't matter whether you're connecting back to get a whole new page, or whether you're doing some socket hackery under the covers to return a response to some jscript code. Either way, you're waiting for a server that's servicing a bazillion other people, so conceptually you might as well be running CICS thirty years ago.
Yeah, yeah, the screens are prettier now, you can download jscript and java applets, yadda yadda. You could program the 3270, too, with sufficient pain. Wake me up when this jscript shit actually works reasonably well. Just coming up for air after writing a few pages of it, and boy am I pissed. Standards all over the place. IE style.backgroundColor is "#ffffff", FF's is "rgb(255, 255, 255)". There are religious wars over "document.all", with some w3c fanatics claiming the world should have to write hideous tree-walkers to iterate over the DOM (so prove me wrong, post a code frag to show how easy it is). It never ends.
(that 3270 keyboard was GREAT. Nothing like it today. Typing on spongebob squarekeys at the moment).
It looks like the technology is finally converging towards Lisp. Maybe 40 years isn't THAT much, after all...
(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)
Is this different from script callbacks in ASP.NET? It allows you to hit the server on an already loaded page and selectively update its contents. While the full abstracted implementation will be available in ASP.NET 2.0, you can easily implement it in the current ASP.NET 1.x.
t tingEdge/
http://msdn.microsoft.com/msdnmag/issues/04/08/Cu
You could use the JSON as message format with hidden iframes, too.
while (!asleep()) sheep++
Google is currently one of the masters of Javascript.
Look at what they have done, and what they have not done - GMail has a very good interface. But even Google has released some real applications, like desktop search and Picassa.
I really believe the browser model can only be taken so far. As someone else noted, your browser becomes your window manager and pretty soon you develop a little cosmos in there. But that cosmos will always be a subset of the richer cosmos the OS itself offers, and so web apps will be convienent but probably never dominant. There is too much to be gained by going to a desktop app.
What I think will happen instead is that hybrid desktop apps, where part of the UI is essentially JavaScript will emerge and the desktop part is able to do what it does well.
"There is more worth loving than we have strength to love." - Brian Jay Stanley