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/ "
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.
Now my clients' computers can be compromised even faster because this language/protocol is "light weight".
The preceding message was based on actual events. Only the names, locations and events have been changed.
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.
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
So now people can't bookmark specific products
Useful from a commercial point of view. Really rather distracting from a visitor point of view. If I can't block it, I'm likely to find another vendor.
This sounds practical, but at some stage you need to send the user to a new page anyway, and you can calculate new totals without having to make server calls - so you might as well leave telling the server about it until they go to the next stage of the checkout process.
Ummm... why would you want an RSS new ticker on a webpage in the first place?
Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access.
... 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."
It's simply a matter of what trade-offs you want to make. Yes there are platforms that are better for building GUI apps. One, not insignificant, problem after you've created the app however is the issue of updating and/or deployment.
So you get to pick:
"I want everything there is for a GUI (fast, stateful, all the controls, etc)."
-- or --
"I want to ease deployment to my internal and external customers and am willing to go without some GUI elements to gain that."
Another issue is what you are trying to do. Are you attempting to feed realtime data to a user? Are you providing and interface to data that's encapsulated only on the users PC and not on some back-end? One is good for a web app and one not so much.
Then there's also the issue of testing. If you have an app that ends up being an executable somewhere you either have to limit the user to a specific OS/hardware or you have to do some significant exhaustive testing to ensure compatability. With web apps this is reduced (but not eliminated).
Personally I've been a developer on a web app internally for 6 years now. We made the switch from a Win32 application to the web just as I moved to the group. The old app required flying out to a site and installing it (and updates several times a year). It was a maintenance nightmare. Today the web app serves customer service at 7 sites across the country which is an extremely high volume of calls. The same web app also serves 10 external clients and will be opened up to 30 more this year. I would hate to think of deploying an executable to 30 clients considering the problems we had maintaining just one 6 years ago.
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.
Uhmmm... Actually I've been doing this for a while now using iframes and javascript. It's not that hard and also avoids the xml bloat. This just gives a "standard" api to use when doing it. It still uses Iframes you just don't have to create them yourself. Most people who have been doing this already have a set of custom tools to help them do it. The functionality has been there for a while. This will help boost its use though and for that I'm grateful. Gmail makes excellent use of it in their UI making it hugely more useable than most other webmail clients. More people need to be recognizing the, already present, power for dynamic applications in the web.
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
So would you rather download <1K to get the new cost in your cart, or download 100K of HTML and images and have the screen flash to get the new cost? As a web host, would you rather serve 1K or 100K?
The other side is responsiveness of the application. A lot of places use the web for more than shopping carts, and this is the sort of technique that makes a web app seem multithreaded. Don't you like the multithreaded applications you use? Wouldn't it be cool to offer similar speed easily via a web browser? Right now my main option is to have a lengthy process performed in a pop-up window, or post back and start a new thread on the server, which both involve more work than it should.
It strikes me the JSON version would be *much* larger for non-western languages. It can only include non-ascii characters in the data via the use of unicode escapes, which are 6 bytes long (\uXXXX), as compared to 2 in XML using an appropriate charset. It also lacks object references, so can't be made as compact as an arbitrary JS program.
JSON-RPC doesn't seem to be intended for use in interchange, but for websites, since it relies on browser security for the 'efficiency' of being able to use eval() in its JS implementation. That being the case, I can't see why you'd choose to use this rather than return arbitrary javascript to the browser.
How is this news? People have bene doing this forever with javascript and posting to a hidden iframe which can call any of the needed functions on it's parent page.
Want to add a new DIV? Easy. Want to remove/hide some DIV? Easy. Want to change the values of some tags? Easy. Want to do almost anything to any element on the page? Easy. Want to save to your DB? Easy.
And all without refereshing the page once. Easy to implement, easy to use. Nothing new to learn. Any server side tech can be used. Can work with more web browsers than this can, etc. etc.
This seem like it will be against the Model View Controller (MVC) architecture.
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
Weren't Java applets designed to do all the things you mentioned?
If applets failed, what reason is there to believe this technology will fare an better?
Because client-side embedded Java applets are a drastically impractical, inconvenient, bloated and slow way to do trivial tasks like this. (NOTE: not a Java troll - it's an awesome language for server-side and standalone client-side apps).
OTOH, ECMAScript/Javascript is built into every browser produced in (at least) the last 5 years, is fast, has zero startup overhead, and is widely understood by every web developer on the planet.
I rarely see Java applets anymore, for the above reasons. I do, however, see many more Flash apps, which have their own set of problems, including that they require yet another set of 3rd-party software to be installed and configured on the client's computer, rendering it undesirable from the point of view of most shopping and ecommerce sites.
This is an elegant solution to something developers have been forced to use ugly workarounds to achieve for years.
You know they call 'em fingers but I've never seen 'em fing. Oh, there they go.