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/ "
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.
Imagine yourself in 5 years time. The web browser has all this stuff on it which means it is as good an interface as any other GUI widget stack. Firefox or Safari or IE or whatever effectively is the window manager with tabbed browsing and links to your favourite 'applications'.
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.
IE besides - "Web app" is a darn appropriate interface for a lot of things and definitely the single most widely spread and portable one. The inability to request a "callback" value from the server from the JS code is a huge PITA if you've ever tried programming those.
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.
Well, I think you're missing the point.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
> 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.
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.
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.
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.
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.
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.