Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What is JSON, JSON-RPC and JSON-RPC-Java?

Hemos posted more than 9 years ago | from the pushing-the-development-forward dept.

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/ "

cancel ×

317 comments

Sorry! There are no comments related to the filter you selected.

first (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11454625)

got it

O...k..... (3, Funny)

Anonymous Coward | more than 9 years ago | (#11454631)

*finishes reading summary*

ok... so... huh?

Re:O...k..... (3, Informative)

rdc_uk (792215) | more than 9 years ago | (#11454664)

So...

repopulate your product page for a new product WITHOUT reloading the whole page.

Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.

Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.

Write an RSS news ticker in html rather than flash...

Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)

Re:O...k..... (3, Insightful)

dorward (129628) | more than 9 years ago | (#11454793)

repopulate your product page for a new product WITHOUT reloading the whole page.

So now people can't bookmark specific products

Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.

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.

Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.

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.

Write an RSS news ticker in html rather than flash...

Ummm... why would you want an RSS new ticker on a webpage in the first place?

Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)

Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access.

Re:O...k..... (4, Interesting)

rdc_uk (792215) | more than 9 years ago | (#11455048)

"So now people can't bookmark specific products"

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:O...k..... (2, Interesting)

dorward (129628) | more than 9 years ago | (#11455197)

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!

And did you read the list of supported browsers? Only notable omission in the real world was safari...

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:O...k..... (1)

mikael (484) | more than 9 years ago | (#11455028)

It might also be useful for saving application settings/user preferences.

As having to update a complete set of file reading/writing/update routines for every application became rather tedious, we found it more convenient to load and save the files as XML documents, read them into memory and access data settings through getValue/setValue calls.

The downside is that the configuration files are rather bloated. If this data exchange format can help reduce the size of these files, then that can only be a good thing.

Re:O...k..... (3, Insightful)

Zphbeeblbrox (816582) | more than 9 years ago | (#11455207)

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.

Re:O...k..... (1)

witte (681163) | more than 9 years ago | (#11454715)

This is cool. On the fly updating of pages, fetching data from components on the server, without reloading the page. So, no more uploading complete business logic components with pages to avoid page loading each time the user changes a value in e.g. a 'Country' dropdown.

There may already be technology that can do in-page RPC to the server. But it's good to have more than one way to accomplish stuff like this, especially if it's free. And lightweight. (And a brand-spanking-new acronym to impress your peers with.)

Pros and cons? (4, Interesting)

Sierpinski (266120) | more than 9 years ago | (#11454634)

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.

Re:Pros and cons? (4, Informative)

metaparadigm (568438) | more than 9 years ago | (#11454702)

A1. The idea is to make it transparent to the programmer. You can practically just call a Java method from your JavaScript web application. one line of code is required to export or allow access to a server-side object.

A2. Yes, security is an interesting topic. The Java implementation refered to works on a deny all by default - allow specific objects to specific clients. It does require the programmer to think about what methods they are exposing. I have been using it over HTTPS with selective objects exported to authorized clients (using the existing JAAS Java authorization and Authentication framework), so I believe it can be used in a very secure way.

Re:Pros and cons? (1)

Malc (1751) | more than 9 years ago | (#11454708)

Are you referring to "HTML Programmers" (hahaha) or programmers? The thing's bloody easy to use.

Re:Pros and cons? (4, Informative)

Jetifi (188285) | more than 9 years ago | (#11454757)

Well, JSON is a subset of JavaScript object notation, so people who know JavaScript already know this. It's basically a way of transfering structured data between browser and server that is less verbose than XML, and can be eval()ed straight into javacript itself.

Of course, any server receiving this stuff via POST should do the same validity checks it does on anything else it gets from the wire. On the client, IIRC you can only use XMLHttpRequest with the server the document originated from, and neither should you be able to execute script across domains, even within iframes, so the existing browser security model should be sufficient to prevent additional security problems, bugs and exploits notwithstanding...

Accessibility (0)

Anonymous Coward | more than 9 years ago | (#11454864)

Accessibility is the real thorn in the side of this I reckon. We need to realise that we have to keep alternative browsers uptodate as well (I've yet to see a browser take advantage of Aural stylesheets).

The main problem here though isnt the fact that the current crop of accessibiltiy browsers arnt uptodate: its a fundamental change in the way a page is rendered. Before, a complete page would be sent, now with this technology sections of a page can be updated. The trick is to descibe any updates to the user whilst maintaining the concept of staying on the same page.

Don't get me wrong, I'm a web dev with 8 years experience, and I use XMLHTTPRequest with XML-RPC all the time (checkout the excellent js-o-lait library), and I really dig this tech, but just hope it doesnt take us back to "a website for some, a website for the rest" development.

I have only one point to make. (2, Insightful)

Slash Watch (849331) | more than 9 years ago | (#11454636)

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.

Re:I have only one point to make. (2, Interesting)

Anonymous Coward | more than 9 years ago | (#11454683)

XUL and XAMAL are being developed so that all applications WILL run through the intarweb...

Only computationally expensive programs will be relegated to the desktop, everything data orientated will live on the web

Re:I have only one point to make. (1)

agraupe (769778) | more than 9 years ago | (#11454696)

That is true, but, as far as I can see, it has experienced some impressive results, like Gmail (I believe that is what we are talking about, right?). The fact is that GUI programming, and even programming in general, can seem quite daunting to the beginner. Although I am an average-to-good C/C++ programmer, GUI still confuses me for the most part (I always have to refer back to the API, is that normal?). Combining JavaScript and its merits (easy-to-learn, basically a subset of Java and C), with (D)HTML and its merits (the starting point for a lot of programmers, myself included, since you see results fast and it's easy to learn, all "HTML is not a programming language" arguments aside). This could be quite interesting.

Re:I have only one point to make. (1)

mornfall (718096) | more than 9 years ago | (#11454928)

Since when is JavaScript a subset of Java and C? Refer to http://c2.com/cgi/wiki?JavaScript [c2.com]

I dare to disagree. (2, Insightful)

hummassa (157160) | more than 9 years ago | (#11454710)

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.

Re:I dare to disagree. (3, Insightful)

arkanes (521690) | more than 9 years ago | (#11455010)

Eh. Not really. Auto-updating isn't especially difficult, especially in the close environments most web applications are written for. Java Web Start, for example, is a cinch. It's not too hard to roll your own mechanism either. Web applications are trendy now, though, despite there being no objective advantage in most circumstances.

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. (1)

Klar (522420) | more than 9 years ago | (#11454712)

Believe it or not, it's not necessarily the best interface for a lot of things.
Yes, but how many applications make is so easy to give you access to such a wide variety of viruses? I kid, I kid.

Actually, I agree with the parrent on this one. I prefer applications to have their own gui. This can help where speed of use is an issue. Also, if you buy software, throw the cd in, and all that is on the cd are a bunch of .html files, you are prolly gunna be pretty pissy.

Re:I have only one point to make. (4, Insightful)

MancDiceman (776332) | more than 9 years ago | (#11454718)

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.

Re:I have only one point to make. (0)

Anonymous Coward | more than 9 years ago | (#11454845)

"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."

Which means that my software is full of spyware/adware and my ISP has a copy of all my documents? No thanks...

Re:I have only one point to make. (3, Insightful)

uradu (10768) | more than 9 years ago | (#11454881)

> 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.

Re:I have only one point to make. (1)

PianoComp81 (589011) | more than 9 years ago | (#11454895)

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 problem I have with this network reliability. Many connections go down at least once a day (even if it's only for a few minutes). Also, what if you're using applications provided by someone other than your ISP? The network connection could go down between you and that application. Until networks are as reliable as the phone service (which will be a while - 15 to 20 years maybe?), I can't see people wanting to use this type of service.

Re:I have only one point to make. (2, Insightful)

maxwell demon (590494) | more than 9 years ago | (#11454921)

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.

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 have only one point to make. (3, Insightful)

arkanes (521690) | more than 9 years ago | (#11455082)

What's stopping it from happening is that the features that make a good browser for hypertext are not the same features that make a good client for, say, a business or data entry application. As a quick test, go hit the back button in any web application that uses this sort of technology. Does it do what you expect? Does the "back button" even make sense in the context of what you're doing?

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:I have only one point to make. (4, Insightful)

ceeam (39911) | more than 9 years ago | (#11454721)

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.

Re:I have only one point to make. (5, Interesting)

Malc (1751) | more than 9 years ago | (#11454731)

Web interfaces have two massive advantages: no need to install anything. They also work just about anywhere.

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:I have only one point to make. (1)

TomorrowPlusX (571956) | more than 9 years ago | (#11454968)

I agree, but there is something odd about using OWA on a windows machine: When you first visit ( say, on a clean machine ) it seems to ask you for your Office 2k cd-rom.

I have to assume this is because it's expecting ActiveX controls that office provides. Still, how creepy is it that going to a *website* prompts your browser for your office install cd.

Thank heaven OWA allows other browsers and still provides an acceptable, if degraded, interface.

Re:I have only one point to make. (1)

Malc (1751) | more than 9 years ago | (#11455007)

Interesting. No I haven't tried it on a clean machine... work pre-installed Office 2003 on it. But yes, it does degrade well doesn't it? It's perfectly usable in FireFox.

One more major advantage... (0)

Anonymous Coward | more than 9 years ago | (#11455140)

Eliminate piracy on the spot.

How many people do you think are using a pirated copy of Basecamp?

Coolaid (1)

willCode4Beer.com (783783) | more than 9 years ago | (#11454733)

You just need to drink the coolade.

Haven't you been hearing all the hype for the last few years.
If we make all applications web based then platform doesn't matter. Of course, to implement all the features the PHB wants, well the web app is only gonna work on one platform. And of course, it'll take more time to do web hoodoo-voodoo than it would to just build in C++/Delphi. But, it will run from a "Web Broswer". It'll if a "web" application.

Slashdot crowd shows their technical ignorance (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11454787)

Because once you mention how Flash owns the web application space, the mobile devices space, and more and more web real estate space you will get howled down by people that are usually clever when it comes to technology.

Flash is so far ahead of any competing technology when it comes to developing applications for the web that there is really no point using anything else.

All the points in the article are already addressed by Flash - only the parts of a page that needs to change are loaded, with Flash Remoting RPC calls are made using a tight, efficient binary format - AMF.

It's like the Slashdot crowd are still trapped in the nineties - howling over the skipintros you'll only ever find on German sites nowadays and complaining about the back button as if web applications haven't moved forward from the days of having to click back and forward just to load information from a server.

NO, NO, NO, NOT the browser (0)

Anonymous Coward | more than 9 years ago | (#11454811)

The "browser" is not the issue here. The real issue is HTTP and HTML. Don't shoot the messenger here. Those protocols were NOT designed to create "applications", but are now used to do just that. Stateless connections, wonky navigation, limited widgets, all make for some serious shortcomings. We won't be seeing anything better until we see a major shift in the underlying infrastructure of the "web".

Re:I have only one point to make. (3, Insightful)

hey! (33014) | more than 9 years ago | (#11454834)

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.

Re:I have only one point to make. (1)

Mant (578427) | more than 9 years ago | (#11454841)

Maybe not, but web apps can usually be developed, deployed and maintained far faster and easier than writing custom apps. That can often outweight having the best interface, as long as the interface is good enough.

Trade-offs (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11454853)

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.

Click below to read more about it. (5, Funny)

Threni (635302) | more than 9 years ago | (#11454642)

With all that stuff going on it's a wonder it didn't click itself!

Let me guess... (1)

ceeam (39911) | more than 9 years ago | (#11454651)

Michael Clark usually runs corporate IT meetings, right? I mean - you can't just come with this buzzfest without due training.

Just Great! (1, Insightful)

deutschemonte (764566) | more than 9 years ago | (#11454654)

Now my clients' computers can be compromised even faster because this language/protocol is "light weight".

Re:Just Great! (1)

nagora (177841) | more than 9 years ago | (#11454813)

Now my clients' computers can be compromised even faster because this language/protocol is "light weight".

Are you suggesting that XML is more secure because the average skiddie can't be bothered to type all that bloated markup? You might be right, actually...

TWW

Fix HTML instead? (3, Insightful)

Spiked_Three (626260) | more than 9 years ago | (#11454660)

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.

Re:Fix HTML instead? (2, Insightful)

Malc (1751) | more than 9 years ago | (#11454751)

HTML was designed as a markup language for text. All these things you're complaining about result from trying to shoe-horn HTML in to an application it was never designed for. It still works pretty well though, all things considered.

Re:Fix HTML instead? (1)

Spiked_Three (626260) | more than 9 years ago | (#11455024)

No shit? I complain about HTML not having the ability a lot less then I complain about having to write apps in HTML to begin with. But for some stupid reason, everyone thinks the web is the place to write applications. I wonder where they got such a stupid idea?

Re:Fix HTML instead? (3, Interesting)

TheRaven64 (641858) | more than 9 years ago | (#11454806)

I don't think HTML is to blame so much as HTTP. The integration of something like XMPP into the browser would be a huge improvement, since it would allow arbitrary XML to be pushed to the client without the need for polling (which is ugly, and no less ugly if it's done in the background without the need for full page refreshes.

And what about php? (2, Interesting)

Anonymous Coward | more than 9 years ago | (#11454686)

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 (5, Interesting)

Anonymous Cowherd X (850136) | more than 9 years ago | (#11454695)

Example in JSON:

{"menu": {
"id": "file",
"value": "File:",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}]}}}

The same thing in XML:

<menu id="file" value="File" >
<popup>
<menuitem value="New" onclick="CreateNewDoc()" />
<menuitem value="Open" onclick="OpenDoc()" />
<menuitem value="Close" onclick="CloseDoc()" />
</popup>
</menu>

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:Perfect for the web? I don't think so (1)

LiquidCoooled (634315) | more than 9 years ago | (#11454725)

JSON looks like LISP.

*shudder*

Re:Perfect for the web? I don't think so (1)

MetaMarty (38276) | more than 9 years ago | (#11454804)

Yes, it does look like Lisp, but people often forget that XML does too. XML/JSON is just Lisp in a different syntax.

There's nothing wrong with Lisp. It's one of the most underrated languages today. Programmers today start their eduction learning Java, OO, C and other modern stuff without looking at the foundation of modern computer science. I love the way Lisp can be used to have self contained pieces of code with minimal side effects.

Re:Perfect for the web? I don't think so (1)

OmniVector (569062) | more than 9 years ago | (#11455211)

lisp was at least 50 years ahead of it's time. it will be probably another 50 before people realize functional programming's expressive power.

Re:Perfect for the web? I don't think so (5, Informative)

metaparadigm (568438) | more than 9 years ago | (#11454776)

Yes, although this is an XML DTD discussion. Most DTDs including the XML-RPC and SOAP DTDs don't encode using attribute values but instead using child elements with character data (apparently this is the XML best practice). Much Much bigger.

Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.

The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out. Also try doing 100 RPC calls a second with SOAP in a browser (this can be done with JSON-RPC on a local network - 10ms round trip on simple methods).

Re:Perfect for the web? I don't think so (1)

Anonymous Cowherd X (850136) | more than 9 years ago | (#11454862)

Let's not sacrifice doing something right for momentary convenience. Sure, JavaScript is built into most browsers, but it's a horrible hack and is definitely not something to build upon. XML will become as much an integral part of browsers as JavaScript has and when that happens standardized ways of reducing the bloat will be accepted. There is no need for JSON and its crippled kin.

Re:Perfect for the web? I don't think so (0)

Anonymous Coward | more than 9 years ago | (#11455039)

Much Much bigger.

FUD. XML compresses very well and practically every browser you will ever use supports the gzip transfer encoding with HTTP.

The second requires a bloated JavaScript XML parser (as this is not built in to many browsers)

FUD. Every web browser that JSON targets has an XML parser built in. They didn't call it XMLHttpRequest for nothing.

Also try doing 100 RPC calls a second with SOAP in a browser

FUD. Using XML does not mean that you must use SOAP, in fact Amazon says that their REST API is far more popular than their SOAP API. Both use XML. You can't use SOAP as a reason to dismiss XML.

Re:Perfect for the web? I don't think so (1)

sporty (27564) | more than 9 years ago | (#11455143)


Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.

The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out.


Give us a CPU speed, amount of memory available, amount of memory used, number of cycles used and code for each parser. I want to know the features of these parsers, and why they were chosen (SAX vs XML-Pull vs DOM). I'd like to be able to reproduce your "numbers" on my machine, and if I can, optimize the XML parser used, 'cause 100RPC calls a second vs 10ms round trip using different softwares isn't a fair test.

Otherwise, anyone (I) can say, "nuh uh" and be done with it. :)

ICBW but: Re:Perfect for the web? I don't think so (2, Informative)

StandardDeviant (122674) | more than 9 years ago | (#11454778)

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.

Re:ICBW but: Re:Perfect for the web? I don't think (0)

Anonymous Coward | more than 9 years ago | (#11454800)

(we were targeting IE only)

You should have aimed better, that SOB piece of trash is still around!

Re:ICBW but: Re:Perfect for the web? I don't think (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11455132)

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:Perfect for the web? I don't think so (2, Informative)

EvilJohn (17821) | more than 9 years ago | (#11454788)

I think you're the missing the point. It's not the fact there's those little simple CreateNewDoc() functions, it's the binding to the Java objects on the backend that's simple to create, and that's the part the 'free from bloat'.

Re:Perfect for the web? I don't think so (1)

SvendTofte (686053) | more than 9 years ago | (#11454797)

Importing the datastructure into the language is very easy. In JS you can basicly go "eval(datastring)". No need to either a custom XML walker, or invoke some ActiveX, or create a document/fragment.

Other obvious things, is that the "menuitem" notation in JSON is actually an array, this is not the case in the XML case. There we just have siblings, with coincidentally the same names. So JSON has richer information (this obvious alot of duplication, only one menuitem, instead of three).

Re:Perfect for the web? I don't think so (2, Interesting)

ivec (61549) | more than 9 years ago | (#11455085)

The previous does choose a best-case format for XML, relying on attributes instead of elements whenever possible. To be honest, what would be the actual SOAP encoding for the equivalent JavaScript data structure?

Now what would you think of (dropping quotes and spaces when unnecessary for parsing):
{menu:{id:file;value:"File:";
popup:{menuitem:({v alue:New;onclick:"CreateNewDoc()"}
{value:Open;on click:"OpenDoc()"}
{value:Close;onclick:"CloseDoc ()"})}}}
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.

double edged boon to users (2, Insightful)

willCode4Beer.com (783783) | more than 9 years ago | (#11454698)

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....

Re:double edged boon to users (1)

EvilJohn (17821) | more than 9 years ago | (#11454814)

Yeah, god forbid we actually work for a living, and not whine about it.

Seriously, this is what it means to be a real developer, solving hard problems. It's what good developers do, and what great developers do well.

The next step will be to tie this to a backend framework for easy site building.

Developers perogative to whine (1)

willCode4Beer.com (783783) | more than 9 years ago | (#11454878)

Sorry if my comment sounded like whining. I was commenting on the appropriate USE of a new idea. If web dev wasn't pure hell, I would probably do something else. Its the challenge that makes coming to work worth while.

Actually, since reading the article a while back about the guy who reversed engineered google's thing, I've been thinking about building a library to make this two-way communication between server APIs and a dynamic page.
This package looks like it will be very interesting and might fill the role. And considering I'm a J2EE dev, I suspect it might even play well (based on statements on the site) with my apps.

Re:Developers perogative to whine (1)

EvilJohn (17821) | more than 9 years ago | (#11454913)

That's an interesting idea. I'm looking forward to building something that I can tie back to an EJB3 backend (POJOs) and just massage through session beans. This might take some of the more tedious aspects of EJB->Web Development a lot less painful.

Anyway, this is going to make it's way into my playtime toolbox.

just tested (played) (1)

willCode4Beer.com (783783) | more than 9 years ago | (#11455189)

Ok, I've just downloaded their demo code and played with it a bit. I've also read most of the source code. So basically, we can register java objects, and call their methods from the client in JS. The (un)marshalling basically translates our objects between Java/text/JavaScript. It even appears to work well. :)
I now think this is officially pretty cool.
One mod though, since I tend to think scripting in JSP's is evil, I create and register the objects in my Struts Action class. I then store it in the session object. The jsp just does what it needs to. Now, I should think about putting the object name in the properties file since it gets used by both the Action class and the javascript.
I'm also using Struts URL rewriting to pick the URL of the servlet so I can ensure the URL is context relative and that it gets the user's session id.
Now, I wonder if I can write a class to tie this into the validation framework in Struts. Imagine getting live form field validation.
bua-ha-ha-ha
Slow work days become play days.

Re:double edged boon to dev (1)

witte (681163) | more than 9 years ago | (#11454819)

Well, look at it like this :
As long as PHB want things implemented that they may not really need with technology they may not understand, *we* still have a job.

I for one welcome ou<connection reset by JSON-RPC Overlords>
.

Re:double edged boon to users (1)

dtfinch (661405) | more than 9 years ago | (#11455118)

Thank God I've been doing this on my own for quite some time, and watching it work in every browser, though I've never referred to it as JSON because I'd never heard of JSON.

Nice (1)

wintaki (848851) | more than 9 years ago | (#11454714)

It is nice to be able to do this, but it begs the question - how far should this go? At what point is a browser app indistinguishable from a normal app? Or maybe that's the point?

Enterprise Java application, ha! (-1, Troll)

Anonymous Coward | more than 9 years ago | (#11454743)

Enterprise and Java application, a true contradiction in terms there.

Re:Enterprise Java application, ha! (0)

Anonymous Coward | more than 9 years ago | (#11454893)

Why?
Keeping Scotty from falling asleep at the teleporters.
Perfectly valid Enterprise Java application.

A standard? (1)

tod_miller (792541) | more than 9 years ago | (#11454744)

OK they can call it a standard, but this is just the implementation of a design, that doesn't make it a standard! :-) adoption does. I want to play with it today! I am doing some web stuff... thinking how it will integreate with strust and jsp... hope ok, I am starting to hate struts!

Is spring easy enough to learn without too many 5 hour sessions followed by kicking yoruself and going, oh, I should do that FIRST!!?? (a struts thing..)

But it is great to see it.

In other news msn search B3tA announced it had develped a 'kewl' better than google technology that shows suggested search keywords. Microsoft deny copying google, or reading JSON spec.

AAARRGH! (1)

iantri (687643) | more than 9 years ago | (#11454753)

JSON, JSON-RPC, Java, JavaScript, Perl, TCL, XML, XMLHttpRequest, MSXML, DHTML :BOOM!:

:head explodes from acrynym overload:

Re:AAARRGH! (1)

maxwell demon (590494) | more than 9 years ago | (#11455219)

:head explodes from acrynym overload:

HEFAO? :-)

But anyway, Java and JavaScript are no acronyms at all, and XMLHttpRequest is only partially.

Another language, another standard (2, Funny)

drgonzo59 (747139) | more than 9 years ago | (#11454759)

When will the average programmer be able to keep up? I am sure in India they are already teaching classes on this ;-)

Forget all the acronyms... (0)

Anonymous Coward | more than 9 years ago | (#11454761)

Basically it lets you do a background request asynchronously to update a database or whatever without a page refresh. This makes the users experience better, reduces bandwidth, reduces server load, and is generally a much nicer way of doing things.

I've recently implemented a system using this to talk to a php application and a mySQL database. I didn't use any fancy remote procedure calls - I just made a get request and sent a web page back containing javascript function calls. Simple.

Anyone who can program server side and client side can use this effectively.

Want to see a fantastic example? (2, Interesting)

stanhawkins (852794) | more than 9 years ago | (#11454815)

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

Re:Want to see a fantastic example? (0)

Anonymous Coward | more than 9 years ago | (#11454865)

Remedy is the shitiest, and most horribly-coded application I have ever had to use; my heart goes out to you, who even in the midst of programming misery, can find some small joy to share with others.

This is real beauty.

New exploit techniques ? (2)

Homology (639438) | more than 9 years ago | (#11454826)

"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)....."

I hope I wasn't the only one that shuddered when I read "remote scripting techniques".

uhh, did anyone realize? (0)

Anonymous Coward | more than 9 years ago | (#11454842)

...uses the lightweight JSON format instead of XML (so it is much faster).

So, in other words, the speed this provides is negated by the slow, inefficient, proprietary nature of the POS that is java?

Just what we need.... (2, Insightful)

Adrian.Challlinor (834846) | more than 9 years ago | (#11454846)

... 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."

Pushlets (3, Informative)

tezza (539307) | more than 9 years ago | (#11454855)

http://www.pushlets.com [pushlets.com]

This is a server side push framework based on the same idea. It preceded GMail et alia.

Malarky (1, Flamebait)

sporty (27564) | more than 9 years ago | (#11454867)

This is a lot of junk except in exceptional cases.


We have machines that are now in the gigahertz. Even a 0.5 ghz machine can process XML with some speed.


We have machines that have tons of memory, so even an inefficient DOM parser which loves using memory, can handle a large XML packet (use sax for that).


We have parsers that are a bit smarter than the slow ones, namely XML-Pull parsers and SAX.


When implementing someone else's protocol, something that is readable is awesome, because documentation isn't always there. Using XSLT, you can also port one XML type to another.


We have land lines that can transmit compressed data easily at 11kb/s (based on a 56k modem).


All json provides, is a way to eek out a few less cycles, a little less memory depending on how you parse it, and a few less bytes per second over XML. It's less readable and it isn't as widely used. What problem are we solving again?

Re:Malarky (1)

Transdimentia (840912) | more than 9 years ago | (#11455025)

Wow, I'd suspected this thinking was going on but I hadn't seen such a blatent statement. This seems to parallel the "we've got more memory and disk so lets throw in bloat instead of running 2x as fast".
I have no problem using XML where it makes sense, but if performance is your priority over compatibility, XML rarely makes sense.

Re:Malarky (1)

sporty (27564) | more than 9 years ago | (#11455095)

XML is not faster than a byte position oriented language. What is being provided is not byte oritented. All data is not at a fixed position nor is it hinted by the data format. i.e. when a { is at spot 1, } can be expected at one or a few places distant from it. This language nor XML can do this. They both lose equaly in this department. TCP/IP is a perfect example of compromise for speed. The entire packet except for the data portion is more or less fixed. You know how many bytes you need to read to find things. In JSON AND XML, you can't.

How much more performance are you expecting using this over something like XML? If the packets are throw-away after you get the data, and you are stretching the limits, ala google, how MUCH are you saving and is it really worht it to diverge from something that is clearer, more of a standard, and easier to read/write.

Or instead... (2, Informative)

koehn (575405) | more than 9 years ago | (#11454876)

Why not just replace some of your HTML [ibm.com] instead?

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.

oh so 80's??? (0)

Anonymous Coward | more than 9 years ago | (#11454942)

Umm.. "..that oh so 80's page reloading"... ???

Hello? HTML browsers started around 94..

XML-RPC did this *years* ago (1)

Petronius (515525) | more than 9 years ago | (#11454951)

XML-RPC [xmlrpc.org] did this years ago:

What is XML-RPC?

It's a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.

It's remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.

It works quite well too. Next, please!

Re:XML-RPC did this *years* ago (2, Informative)

togofspookware (464119) | more than 9 years ago | (#11455058)

You missed the part that "XML-RPC sucks".

3270s (2, Informative)

Alrescha (50745) | more than 9 years ago | (#11454952)

"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)

Where does this fit in with W3C standards? (1)

hexene (68121) | more than 9 years ago | (#11454960)

Hopefully this will provide some added incentive for browser makers to support DOM Level 3 Load and Save [w3.org] ...

Character Encoding? (0)

Anonymous Coward | more than 9 years ago | (#11454964)

Interesting that it doesn't specify a way to declare character encoding like XML does.

That's probably a good thing if you're using it with HTTP, where the "Content-Type: blah; charset=UTF-8" can be used, saving duplication / mismatch with XML. Could be a problem though if you store a JSON message in a file.

And what is the MIME type anyway?

Native PHP-JSON data-converter classes (1)

passionplay (607862) | more than 9 years ago | (#11454988)

If anyone wants, I have a native PHP based JSON converter package I've implemented that takes JSON formatted text and creates PHP structures from it, and in other direction, takes PHP structures and creates JSON formatted text. I'm going to try to post it to SourceForge today. If anyone wants it sooner, feel free to reply to this thread. I created this about a year ago, but haven't had the impetus to post it yet, because it seemed esoteric at best and I wasn't sure anyone would need it. Now that JSON is becoming more prevalent, the need seems to be present. Thanks.

Re:Native PHP-JSON data-converter classes (1)

metaparadigm (568438) | more than 9 years ago | (#11455159)

When you've put it on the web, send a mail to the author of this page: http://www.crockford.com/JSON/ I'm sure he'll be interested.

JSON in japano (1)

fforw (116415) | more than 9 years ago | (#11454995)

Although I haven't called it JSON this is kind of exactly what I called "javascript views" in my web application toolkit [sourceforge.net] . One small part of my project uses serverside java to generate dynamic javascript objects which are a javascript representation of nested java object graphs. The syntax of the generated js object source is a bit different because I did not know that the language constructs used by JSON exist (I think I'll switch to JSON very soon).

Online Demo showing the javascript view feature. [logotopia.net]

Project Documentation. [sourceforge.net]

( Funny thing is my story about this was just rejected this morning.)

JS usage? (1)

thisisauniqueid (825395) | more than 9 years ago | (#11455046)

Isn't it dangerous to evaluate JSON on the js side by calling Javascript's eval() ? The server could be returning anything, not just JSON-valid JS syntax.

Mind you, if there's a non-JSON JS exploit that could be taken advantage, I guess you could put it straight into JS code in the HTML, and the user would be just as vulnerable as if the exploit were run using eval().

Is this the real thing? (1)

ZakMcCracken (753422) | more than 9 years ago | (#11455121)

This is very, very, very cool for designers of complex web applications. But is this the real thing that Google uses?

Oh no... (1)

KontinMonet (737319) | more than 9 years ago | (#11455195)

And, no doubt, JSON etc. will work exactly the same across browsers/platforms and any combination of client/server platform. There will be no surprises. Yeah right.

And all those crappy Javascript 'programs' are going to be magically transformed into high-quality type-safe rock-solid modules by the same people who wrote the crap JS in the first place?

I won't hold my breath on this one...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?