![Java Java](http://a.fsdn.com/sd/topics/java_64.png)
![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![The Internet The Internet](http://a.fsdn.com/sd/topics/internet_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
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/ "
O...k..... (Score:3, Funny)
*finishes reading summary*
ok... so... huh?
Re:O...k..... (Score:4, Informative)
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..... (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: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: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 t
Re:O...k..... (Score:2)
And the VALUE to put in the SRC - which is what this would allow you to pull down as/if required.
Re:O...k..... (Score:2)
<a href="product-page-with-image-2"
onclick="return changeProductImage('product', 'image-2.jpeg');">Action shot</a>
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:O...k..... (Score:2)
If your HTML document containing little more then a list of products is 100 kilobytes, then its very very badly written. You should solve the problem by writing better HTML rather then trying to avoid downloading it.
Re:O...k..... (Score:2)
Ok, change that number to 4K and reread the post. Or are you the type who likes to program in assembly, and prefers human labor over machine labor?
Re:O...k..... (Score:2)
Re:O...k..... (Score:2)
If I hadn't already decided to buy your stuff, I wouldn't be reading your page. You don't need to attract my attention; my presence proves that you already have it.
Re:O...k..... (Score:2)
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
Re:O...k..... (Score:3, Insightful)
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.
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:Pros and cons? (Score:4, Informative)
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? (Score:2)
Re:Pros and cons? (Score:5, Informative)
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...
Re:Pros and cons? (Score:2)
And if you're not doing that, then you're writing some other kind of clients that can do more than ht
Re:Pros and cons? (Score:3, Informative)
You're right, the expected client is JavaScript, inside a browser. The frontend UI is typically in HTML (or SVG), but the client-side logic is written in JavaScript. In this case, the request/response happens within a web-page, between the browser and the web server.
HTML forms are one mechanism for client-server data transfer in a browser, but posting them necessitates reloading the entire web-page, or an iframe, which is not seamless for interfaces like Google Suggest, and may be overkill if you're only
Re:Pros and cons? (Score:2)
I have only one point to make. (Score:2, Insightful)
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
Re:I have only one point to make. (Score:2)
I dare to disagree. (Score:2, Insightful)
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:2)
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
Re:I have only one point to make. (Score:2)
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: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, 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 _ faq.html#anchor19 [apple.com].)
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 re
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
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:I have only one point to make. (Score:2)
But there are plenty of things that aren't:
-It is nearly impossible to make a more advanced text widget than what are available in html already.
-Rendering images takes a long time in interpreted languages by nature (of course, javascript could become JIT and this problem would be gone).
-You're sandboxed into the browser. You can't interact with other desktop apps. To do so woul
The browser model is ok,the implementation sucks (Score:2)
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
Re:I have only one point to make. (Score:5, Insightful)
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:I have only one point to make. (Score:2)
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. (Score:2)
Re:I have only one point to make. (Score:2, Interesting)
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.
Re:I have only one point to make. (Score:2)
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.
Re:Coolaid (Score:2)
Did you mean: kool aid [google.com]
Click below to read more about it. (Score:5, Funny)
Let me guess... (Score:2)
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.
Re:Fix HTML instead? (Score:3, Insightful)
Re:Fix HTML instead? (Score:4, Interesting)
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:Perfect for the web? I don't think so (Score:5, Informative)
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 (Score:2)
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 li
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
ICBW but: Re:Perfect for the web? I don't think so (Score:3, Informative)
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.
Re:Perfect for the web? I don't think so (Score:3, Informative)
Re:Perfect for the web? I don't think so (Score:2)
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 (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 generat
Re:Perfect for the web? I don't think so (Score:2)
Well, you can also just use an XSLT to translate the meaningful XML into JSON, or whatever other standard your heart desires.
So, you're both right.
Re:Perfect for the web? I don't think so (Score:2)
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. Im
Re:double edged boon to users (Score:2)
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 (Score:2)
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 r
Re:Developers perogative to whine (Score:2)
Anyway, this is going to make it's way into my playtime toolbox.
just tested (played) (Score:2)
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
With JSON-RPC nothing new to learn (Score:2)
Using the JSON-RPC package, you don't actually have to touch and JSON. Just plain old Java/JavaScript. The package does the conversion for you.
In the (un)marshalling stage the text representation of the objects, is actually the JSON. But, since the package does this step for you (each way), you don't have to mess with it.
So, now we have a new toy but, don't *really* have to learn anything new. Now, if someone wanted to do a PHP,ASP, or insert favorite scripting lang h
Re:double edged boon to users (Score:2)
AAARRGH! (Score:2)
Re:AAARRGH! (Score:2)
HEFAO?
But anyway, Java and JavaScript are no acronyms at all, and XMLHttpRequest is only partially.
Another language, another standard (Score:2, Funny)
Re:Another language, another standard (Score:2)
The scary part is, I happen to know (from working with Indians) they ARE teaching classes on this stuff, or at least similar stuff. I could use some classes myself. I just wrote a few pages of jscript and I am in severe browser standards pain just like I was the last time I did this, 2 years ago. There's still
Want to see a fantastic example? (Score:2, Interesting)
New exploit techniques ? (Score:3)
I hope I wasn't the only one that shuddered when I read "remote scripting techniques".
Just what we need.... (Score:2, Insightful)
Pushlets (Score:4, Informative)
This is a server side push framework based on the same idea. It preceded GMail et alia.
Malarky (Score:2, Flamebait)
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
Re:Malarky (Score:2)
Re:Malarky (Score:2)
Or instead... (Score:3, Informative)
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.
XML-RPC did this *years* ago (Score:2)
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 (Score:2, Informative)
Re:XML-RPC did this *years* ago (Score:2)
3270s (Score:3, Informative)
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)
Re:3270s (Score:2)
Back to the future: Web = CICS? (Score:3, Informative)
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as
3270 keyboard (Score:2)
Dammit, you had to bring up the best keyboard ever made. Now I've got an erection. I'm such a nerd.
JSON in japano (Score:2)
Online Demo showing the javascript view feature. [logotopia.net]
Projec [sourceforge.net]
Oh no... (Score:2)
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...
uh (Score:2)
Mr. Grammar has left the building.
S-expressions (Score:3, Funny)
(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)
Different than ASP.NET script callbacks? (Score:3, Interesting)
http://msdn.microsoft.com/msdnmag/issues/04/08/Cu
Python binding (Score:2)
JSON Rocks - Here are some ideas (Score:2)
1) Server to client hashmaps:
JSON is great for passing hashmaps of data and for storing specifications meta data for applications.
eg:
ServerReport={serverFailed: true, errorMessage: "you used XML dummy"}
2) Application meta data:
Storing application configuration using JSON is not only efficient but very easy to ma
Re:Just Great! (Score:2)
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
Apples vs. Oranges (Score:2)
JSON is an RPC API for javascript, that is implemented by a simple on-wire data represenation.
The W3C XML encryption standards [w3.org] notwithstanding, security is clearly a concern outside the scope of simple data respresentation. However, this is NOT the case for a RPC system.
After spending a few minutes futzing around with this, clearly this is pretty interesting stuff. However what is missing is a sense of what best practices for security are in a JSON application. Is secu
Re:Just Great! (Score:2)
If you can't write a secure web application you are fucked in any case. If the web application is well written this makes absolutely no difference from a security point of view.
In most cases implementations will use this as javascript enhanced alternative to a static html page based web application. The website will expose the same objects with the same data it does via html. The only difference
Re:first (Score:2)
Advantages to hidden iframe (Score:3, Informative)
You could use the JSON as message format with hidden iframes, too.