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/ "
Pros and cons? (Score:5, Interesting)
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.
Re:I have only one point to make. (Score:2, Interesting)
Only computationally expensive programs will be relegated to the desktop, everything data orientated will live on the web
And what about php? (Score:2, Interesting)
If you want to interoperate with PHP, I'd suggest Harry Fuecks JPSPAN [sourceforge.net] 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 [james-carr.org]
Perfect for the web? I don't think so (Score:5, Interesting)
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.
Re:I have only one point to make. (Score:5, Interesting)
You're right: a web page for a complicated will rarely match the UI of a dedicated application. Take Outlook's Web Access UI: it's pretty amazing, especially if you're using IE. It can be used almost anywhere without having the latest version of Office installed. It's still damned clunky compared with real Outlook, but sometimes it's better than nothing.
Re:Fix HTML instead? (Score:4, Interesting)
Want to see a fantastic example? (Score:2, Interesting)
Re:O...k..... (Score:5, Interesting)
Fair comment, though I can think of places where similar features are desirable -> changing product images is a better usage.
"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."
Good luck; sites designed to sell tend to ADVERTISE their wares. You seem to be thinking 3-second rotation; I'm thinking more 1-minute rotation of current "specials". Put bluntly; I have clients that will pay me to do this if its possible.
"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."
1; I don't want the mechanism for calculations at the client side, so the calculation would require a reload, therefore this will make the page more responsive; i.e. better. The reason for non-client side? First: javascript is a shit language for anything other than DOM manipulation. Second: clients don't want their business logic exposed in javascript. Third: we don't want to download all the data required for those calculations to the client (prices in a code-manipulatable form should NEVER get to the client side, or be sent via post/get, prices just get displayed to the client, not manipulated by them)
Think about a checkout that calculates shipping costs globally; you need the location from the client. Depending on location the methods available for shipping will change. Depending on weight of goods (changes with quantity change) and location, the costs for each method change.
Thats a LOT of information to download to the client's machine to make the totals update without a server-call. Its also a ton of information (including prices) that I don't want the client side to have access to, and that I don't want javascript responsible for calculations on.
If I can pull down just the new value, rather than the whole page -> better!
"Ummm... why would you want an RSS new ticker on a webpage in the first place?"
Again; clients will pay for it. Just because YOU don't want it (or, in fact, that my client's clients don't want it), doesn't mean it has no value.
"Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access."
There are plenty of advantages to not using flash. (reduce number of languages required to display 1 page and reduce number of external plugins required to display 1 page to name just 2 advantages)
Iframes are never a good idea.
And did you read the list of supported browsers? Only notable omission in the real world was safari...
2;
Re:Perfect for the web? I don't think so (Score:2, Interesting)
Now what would you think of (dropping quotes and spaces when unnecessary for parsing):Now what if built-in filter allowed you to generate either this compact blurb, or a neatly auto-formatted and indented form?
The JSON format (which I just discovered) is nearly identical to a format I have been using for 10+ years - with which this sample is compatible. The i/o implementation I use internally is in C++, and supports a binary, compressed, and encrypted formats as well. An incomplete rewrite of it in C is available at http://ivan.vecerina.com/code/datatree/ [vecerina.com].
I like JSON more than XML - because it offers a natural representation of hierarchical data structures seen most languages: a tree of records(/objects), arrays(/collections), and leaf values(/simple data fields).
XML has many qualities, but it is not the natural solution/format for such data structures. When should text data be used in XML? When should you use an element rather than an attribute in XML?
XML forces you to either select a standardized mapping that introduces redundant clutter (SOAP), or accept the complexity of an application-specific mapping.
Re:O...k..... (Score:3, Interesting)
So (some) Vendors want it, and (some) Web Developers want it becuase the Vendors (their clients) want it - but does it bring any serious benefit to the end user?
Changing product images is a reasonable thing to do - but all that needs is a change in the src of the <img> (Or you can take the thinkgeek approach and have nice, large images that show lots of details and that a full page reload doesn't add any significant bandwidth needs to)
1-minute rotation? How long to people spend on a single page that they aren't reading carefully (and don't want to be distracted)? Just pick a special at random with each new page. Amazon has a "related produts" which works rather well IMO.
I accept your point about the price calculations, for things where the postage et al isn't simple there could be some benefit. However, do people really fiddle the quantities up and down so much that the occasional reload is going to be a noticable detraction of service?
I can't say that I'm really pro-Flash or pro-Iframes (OK, I'm very much against them), but you say "Iframes are never a good idea." without giving any reasons - I can think of quite a few reasons why Iframes are a bad idea - but this JavaScript solution has all of those problems too - but with worse browser support!
I would really love it if it weren't so - but not everybody upgrades to the latest and greatest version of their browser. Some people still use Netscape 4. (And Safari was on the list).
Re:I have only one point to make. (Score:2, Interesting)
Different than ASP.NET script callbacks? (Score:3, Interesting)
http://msdn.microsoft.com/msdnmag/issues/04/08/Cu
Re:Pros and cons? (Score:2, Interesting)
On the other hand, if your page is mostly data which will be changing (e.g. a database-backed web form), the vaunted performance isn't that much better than just slimming your HTML using CSS. And if you just use simple HTML (with CSS), you can have something which also works on lynx or older browsers, while still looking sharp on Firefox/IE/Safari/Opera/etc.
Re:I have only one point to make. (Score:3, Interesting)
*use xhtml only
*use extremely light html (under 10k if I can help it)
*no graphics
*no fancy nothing
*javascript sparingly (and yes I use xml-rpc to do no-refresh data submits) (Apple, fix Safari's DomParser stuff. See http://developer.apple.com/internet/safari/safari
As far as server technology, remember to load the minimum (files, class libs, etc), optimize db queries, split pages logically for the USER, pool db connections, and return the page in 0.4 seconds (my intranet pages average
And yes, I do do this for a living.
Last but not least: do not, I repeat, do not write code that depends on IE. I'm not saying Firefox or Opera are taking over, I'm saying IE7 on Longhorn will break just enough of your IE 5.01 apps to propel you into howling fits of deranged rage.