What is JSON, JSON-RPC and JSON-RPC-Java? 317
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/ "
I have only one point to make. (Score:2, Insightful)
Just Great! (Score:1, Insightful)
Fix HTML instead? (Score:3, Insightful)
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.
double edged boon to users (Score:2, Insightful)
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....
I dare to disagree. (Score:2, Insightful)
Re:I have only one point to make. (Score:5, Insightful)
The interface is fluid, keyboard shortcuts working fine and everything is as responsive as it is right now in your current desktop. Your applications are used over the web - you don't have to worry about software upgrades or fixing your parent's computer after some installation as everything is done by your ISP.
Can you see that future? What is stopping it from happening?
You're right, the browser is a crap interface. If you actually understood the technology being described, you would realise that it is an improvement to the interface to make all those things happen.
The browser is a bad interface right now. JSON helps to make it a more suitable interface. Go figure.
Re:I have only one point to make. (Score:5, Insightful)
Re:Fix HTML instead? (Score:3, Insightful)
Re:O...k..... (Score:4, Insightful)
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.
Re:I have only one point to make. (Score:4, Insightful)
These applications areng going to use a browser interface. The are going to use the browser as a platform on which non-browserish presentation layers can be constructed.
This is exactly the future that caused Microsoft to go bezerk over Netscape all those years ago.
Just what we need.... (Score:2, Insightful)
Trade-offs (Score:1, Insightful)
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.
Re:I have only one point to make. (Score:4, Insightful)
> understood the technology being described, you would realise
> that it is an improvement to the interface to make all those
> things happen.
No, a real improvement to the interface would be to move away from any technologies that mix (D)HTML and executable code. It's a recipe for unmaintainability and for driving self-respecting desktop developers to despair. True advances in distributed apps are approaches such as Mozilla's XUL. Alas, they're a step away from the quasi-declarative "programming" of (D)HTML back to the procedural programming of C and its descendants, not something artsy web "developers" like to hear.
Re:I have only one point to make. (Score:3, Insightful)
Exactly that is something to worry about! Imagine you are writing something important with a web-based word processor. You are close to deadline, and all you have to do now is to print out that stuff (or to convert it to PDF and mail it). Nobody would be so insane to update his word processor at exactly this point. But with web applications, it's your app provider who decides when to update. Since at every time there's likely someone who is close to deadline with sonething, so the provider cannot avoid that. And the new version may have a slight bug or incompatibility which doesn't affect 99.9% of all users but completely breaks your file. Now remember you are close to deadline. Sucks, eh?
Of course, I guess MS would dream of web applications: Don't charge for the program, charge for the time you use it! You are slow in writing? Well, too bad for you, you'll pay more! Of course in addition to paying for your internet access (with normal apps I don't need to be online unless I want to explicitly get data from the net or send data to the net; with web apps, you'll have to be online even for writing a simple text!) I don't think they (as well as many other companies) could withstand the temption.
I guess in the world you envision (all apps are web based), paper and pen would get a revival (because writing with pen on paper is just cheaper). The text program would likely be started up only for typing in the final text.
Also, web applications are very volnerable to DoS attacks. Imagine Word would be replaced by a hypothetical WebWord. Now you have just to make a DoS attack on the WebWord server, and suddenly nobody could edit his WebWord documents!
No thanks, I prefer to have my software on disk.
Re:I dare to disagree. (Score:4, Insightful)
Refresh-less updating isn't new, either - I've been doing it for at least 3 years, without the XML stuff. Even with it there's only so much you can do on the client, by design. The web is a decent platform for reporting. It's a good place for universal access (see gmail, for example). It's a lousy place to put your data-entry heavy business applications.
Re:I have only one point to make. (Score:4, Insightful)
Hypertext is a lousy way of writing applications - in fact, most "web apps" have roughly zero relationship with hypertext. Network-transparent thin clients are interesting, but HTML/DHTML/current browsers are the wrong way to implement these things. Part of the problem is the issue of control - client applications need to be able to control the user interface to a degree that a general purpose browser simply can't allow. Something as simple as "Save changes at exit" is impossible in a browser - and you wouldn't want it to be. Same thing with control of the back button, or spawning new windows (or even dialogs, which you can do with IE).
In short - the browser is a fundamentally poor platform for most applications. More to the point, we have and have had the technology for network-based application suites for years. ASP (application service providers, not the MS web platform) is gaining some mindshare, but it's not taking off like gangbusters.
Re:ICBW but: Re:Perfect for the web? I don't think (Score:2, Insightful)
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 [w3.org]. 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.
Re:O...k..... (Score:3, Insightful)
Re:O...k..... (Score:4, Insightful)
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.
Re:Perfect for the web? I don't think so (Score:3, Insightful)
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.
Re:first (Score:1, Insightful)
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.
Against the Model View Controller (Score:1, Insightful)
Look to Google for the future (Score:3, Insightful)
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.
Re:O...k..... (Score:4, Insightful)
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.