Slashdot Mirror
What is JSON, JSON-RPC and JSON-RPC-Java?
Michael Clark writes "Seen those funky remote scripting techniques employed by Orkut, Gmail and Google Suggests that avoid that oh so 80's page reloading (think IBM 3270 only slower). A fledgling standard is developing to allow this new breed of fast and highly dynamic web applications to flourish.
JSON (JavaScript Object Notation) is a lightweight data-interchange format with language bindings for C, C++, C#, Java, JavaScript, Perl, TCL and others. It is derived from JavaScript and it has similar expresive capabilities to XML. Perfect for the web as doesn't suffer from XML's bloat and is custom made for our defacto browser language.
JSON-RPC is a simple remote procedure call protocol similar to XML-RPC although it uses the lightweight JSON format instead of XML (so it is much faster).
The XMLHttpRequest object (or MSXML ActiveX in the case of Internet Explorer) is used in the browser to call remote methods on the server without the need for reloading the page.
JSON-RPC-Java is a Java implementation of the JSON-RPC protocol.
JSON-RPC-Java combines these all together to create an amazingly and simple way of developing these highly interactive type of enterprise java applications with JavaScript DHTML web front-ends.
" Click below to read more about it.
"Now is the turning point. Forget that horid wait while 100K of HTML downloads when the application just wanted to update one field on the page.
The XMLHttpRequest object has made it's way into all the main browsers with it's recent introduction into Opera and Konqueror (sans the Konqueror bug).
This new form of web development now works on Internet Explorer 5, 5.5, 6, Mozilla, Firefox, Safari 1.2, Opera 8 Beta and Konqueror 3.3 (with a much needed patch).
Appeal to Konqueror users - please log into the KDE bugzilla and vote on this bug
so you to can experience this wonderful thing.
More details here: http://oss.metaparadigm.com/jsonrpc/ "
*finishes reading summary*
ok... so... huh?
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.
And they said zombies weren't real!
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.
With all that stuff going on it's a wonder it didn't click itself!
Michael Clark usually runs corporate IT meetings, right? I mean - you can't just come with this buzzfest without due training.
Now my clients' computers can be compromised even faster because this language/protocol is "light weight".
The preceding message was based on actual events. Only the names, locations and events have been changed.
I've had to resort to all sorts of tricks to avoid postbacks in my current (aspx) development efforts. First we used a thrid party soap-xml RPC like this thing. Then we switched to an IFrame for the postback portion. Then I noticed that MS is including their own new and improved soap-xml RPC thing in .Net 2. Now I read about this.
Seems it is a problem a lot of people need/want to solve - but to be honest, I am tired of having so many different solutions to a problem I should not have to begin with. Isn't there something that can be done with the HTML standard to elliminate the need? Life would be so much better down that path.
slashdot troll = you make a compelling argument I do not like the implications of.
If you want to interoperate with PHP, I'd suggest Harry Fuecks JPSPAN 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
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.
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....
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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?
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.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
When will the average programmer be able to keep up? I am sure in India they are already teaching classes on this ;-)
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.
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.
News for Geeks in Austin, TX
(we were targeting IE only)
You should have aimed better, that SOB piece of trash is still around!
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".
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
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>
.
I hope I wasn't the only one that shuddered when I read "remote scripting techniques".
...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?
... 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."
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.
This is a server side push framework based on the same idea. It preceded GMail et alia.
[% slash_sig_val.text %]
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.
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?
-
ping -f 255.255.255.255 # if only
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.
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.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Why?
Keeping Scotty from falling asleep at the teleporters.
Perfectly valid Enterprise Java application.
Umm.. "..that oh so 80's page reloading"... ???
Hello? HTML browsers started around 94..
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!
there's no place like ~
"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)
...bringing you cynical quips since 1998
Hopefully this will provide some added incentive for browser makers to support DOM Level 3 Load and Save...
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?
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.
Online Demo showing the javascript view feature.
Project Documentation.
( Funny thing is my story about this was just rejected this morning.)
while (!asleep()) sheep++
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().
This is very, very, very cool for designers of complex web applications. But is this the real thing that Google uses?
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. 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.
Eliminate piracy on the spot.
How many people do you think are using a pirated copy of Basecamp?
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.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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...
Did he inhale?
Link doesn't seem to work at all in my AOL Fire Fox (?). I wanted to buy a mac since I keep filling up my screensaver with spyware, but this search engine my nephew installed for me doesn't work. Please help.
I forgot to mention in my previous POST.
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 here type RPC package they would have to learn JSON but, once the bridge was built, they wouldn't need to bother with it any more.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Funny - My "web experience" is almost always a lot nicer when I disable Flash (which is most of the time these days)...
Alright! I can view more porn, faster!
Yes, mainframes are really, really good at I/O, which is a concept that many people didn't get (DEC for one, when they fell flat on their faces trying to leverage the VAX into mainframe land) and still don't get. The CDC 7600 was surrounded by 6600's to spoon feed it, just as IBM mainframes have channel controllers (real processors) separate from the CPU to do the same thing.
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as it did at our shop multiple times per day? And maybe you could pump bits at it pretty fast, but under TSO your Q1 response time was 10 to 20 seconds during peak times, so it didn't really matter how high-speed the intrinsic channel was.
3270's were designed for forms entry with CICS apps, basically. It's a record-oriented device (like all IBM devices) which just doesn't add up to a very good user experience. You need character interrupts, and you need fast service for those interrupts. The mainframe secret is to let the CPU compute uninterrupted by batching up terminal I/O, screw the user.
Which is exactly the Web experience today. Fill in a form, press a button, wait. Back to the future! In the limit, it doesn't matter whether you're connecting back to get a whole new page, or whether you're doing some socket hackery under the covers to return a response to some jscript code. Either way, you're waiting for a server that's servicing a bazillion other people, so conceptually you might as well be running CICS thirty years ago.
Yeah, yeah, the screens are prettier now, you can download jscript and java applets, yadda yadda. You could program the 3270, too, with sufficient pain. Wake me up when this jscript shit actually works reasonably well. Just coming up for air after writing a few pages of it, and boy am I pissed. Standards all over the place. IE style.backgroundColor is "#ffffff", FF's is "rgb(255, 255, 255)". There are religious wars over "document.all", with some w3c fanatics claiming the world should have to write hideous tree-walkers to iterate over the DOM (so prove me wrong, post a code frag to show how easy it is). It never ends.
(that 3270 keyboard was GREAT. Nothing like it today. Typing on spongebob squarekeys at the moment).
Anyone has experience with ASN.1 http://asn1.elibel.tm.fr/en/? JSON seems to be aiming in the same direction but I don't quite understand what is it they want to do differently.
Can anyone explain this please?
The new frames!
XML is a way of repreenting data.
/JSON-RPC to com.metaparadigm.jsonrpc.JSONRPCServlet, you get no security whatsoever. Once an attacker figures out the URL patterns of your system (which would be very easy, especially if he can sniff packets on your network), your objects are basically wide open.
JSON is an RPC API for javascript, that is implemented by a simple on-wire data represenation.
The W3C XML encryption standards 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 security supposed to be handled by the remote objects? By the application container? By the transport layer?
A quick look at the JSONRPCServlet code makes it look like no thought has been given to security at all. It merely checks for a session and creates one if it doesn't exist. So, if you are simply mapping
Experience has shown that not thinking about security in a network.
My guess it that best practices for security in a JSON applicaiton would include a combination of TLS for on-wire security and AOP to your remote callable objects. You could put an adapter around com.metaparadigm.jsonrpc.JSONRPCServlet to perform some kind of security check on requests, maybe checking authentication credentials against a set of configuration files. This would in effect be a kind of aspect oriented programming wrapped around your remoteable objects, without any special AOP magic.
My sense is that this would have the potential to be reasonably secure, while remainign orthagonal to the overall model and so maintain the original simplicity. These JSON folks should consider making this mandatory -- to have a role/method security registry that would cause an error to be thrown if somebody exceeded their rights. The servlet could then be configured in one of two differnt modes: allow-if-not-forbiiden, or forbid-if-not-allowed. The allow-if-not-forbidden mode of the servlet would work just as it does now in the absence of any security configuration information.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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).
Mr. Grammar has left the building.
I vote for the majestic wilderbeast.
And Javascript, for that matter.
I use the PrefBar extension in Mozilla. I click a radio button to turn JavaScript on for the two minutes I spend logging in to my bank. Rest of the time, that shit stays off.
(who lusts for the feel of a 3270 keyboard under his fingers)
:)
Dammit, you had to bring up the best keyboard ever made. Now I've got an erection. I'm such a nerd.
It looks like the technology is finally converging towards Lisp. Maybe 40 years isn't THAT much, after all...
(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)
That's "wildebeest" idiot.
Check out this guy's page for an example: http://members.ozemail.com.au/~dcrombie/java/Pend
...welcome our new acronym overlords.
Is this different from script callbacks in ASP.NET? It allows you to hit the server on an already loaded page and selectively update its contents. While the full abstracted implementation will be available in ASP.NET 2.0, you can easily implement it in the current ASP.NET 1.x.
t tingEdge/
http://msdn.microsoft.com/msdnmag/issues/04/08/Cu
I can see a couple issues - Python uses None instead of null and Python doesn't always play nicely with Unicode - but a Python *binding* will be *very* lightweight.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
I was converted to using JSON about 2 years ago to enable my rather complex DHTML applications to go to the next level. The transition was so sucessfull that I now use JSON in many levels such as:
// Private - Condition Index Log // Private - Condition index // Read only - use setElem // Read only, setAtts() ...
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 maintain and read.
3) Singleton Object Declaration for utility objects:
By using JSON to define objects in JavaScript, a singleton object can be used very well to be used as utility objects. By nesting the methods and properties within a JSON spec, you can save on namespace. And as any script programmer (especially JavaScript), namespace is everything.
eg: (real exerpt)
_SC=SearchComponent={
log: [],
ind: -1,
elem: null,
atts: [],
buildBody: function SC_buildBody(){
return _GUI.buildCurveTable(
(
"table
4) Function/method arguments:
When dealing with many arguments of functions, often the calling code and the method/func get out of hand. By using JSON to pass arguments, you can still read your code from both ends.
ie: (another real exerpt I wrote yesterday)
function ExtNav_downloadFile(j){
if(
!isJSON(j) ||
!isJSRec(j.fileRec) ||
!isBool(j.lock))
{ debugErr("j must a JSON and contain: fileRec: ~JSRecord~, lock: ~Bool~") }
if(!confirm(ExtNav.buildCMText({ action: (j.lock?"checkout":"download"), fileRec: j.fileRec, userRec: User, popup: false}))){return}
ExtNav.postIt(
(j.lock?"checkout":"download"),
[
"oid",j.fileRec.ID,
"type",j.fileRec.Type,
"filename",j.fileRec.FileName
]
)
}
One important note though, It is still better to pass tables of data without the fields being specified. It should be the programmers job to understand that the server sent a table with n fields that are in a particular order. By only passing the data (in a JavaScript array not JSON), the data size is greatly reduced. ie:
aTableDat=[
["r1f1","r1f2","r1f3"],
["r2f1","r2f2","r2f3"]
]
Another interesting thing is that Python has JSON natively interpreted like JavaScript. Meaning that a Python based servlet could very efficiently communicate information with the client application.
JsD
[Use FireFox and JSON or Die:]
How is this news? People have bene doing this forever with javascript and posting to a hidden iframe which can call any of the needed functions on it's parent page.
Want to add a new DIV? Easy. Want to remove/hide some DIV? Easy. Want to change the values of some tags? Easy. Want to do almost anything to any element on the page? Easy. Want to save to your DB? Easy.
And all without refereshing the page once. Easy to implement, easy to use. Nothing new to learn. Any server side tech can be used. Can work with more web browsers than this can, etc. etc.
This seem like it will be against the Model View Controller (MVC) architecture.
The distributed app model (i.e. passive connection, declarative programming, flow-oriented MMI) is very very good. That's a good concept. But the implementation really sucks. Developing distributed applications via this model is very immature, at the very best. It is difficult since there are tens of domain-specific programming languages to learn, the binding between them leaves a lot to be desired, and debugging is almost non-existent. It's very clear to those who have developed (or tried to develop) distributed apps that go beyond the 'write some data to the db' problem that a better implementation of the distributed app model is needed.
That's what I've been wondering about too. Does this newer tech have some inherent advantage over the hidden iframe method? Is it just more structured?
Ideally, this is the place where your server-side library like Tapestry that already generates html widgets that link back up to server calls come in handy. You DON'T have to write out this stuff by hand, it's generated by the server according to your parameters.
Then all the worries about ANOTHER programming language and ANOTHER place to introduce un-maintainable code just go out the window. Someone who knows what s/he is doing writes a widget that is well documented and tested. You employ it according to it's API and POOF! your web-based UI just got XMLHttpRequest-ified(TM).
The use of Javascript and Java -- i.e. languages that run code on *your* computer, vs. HTML which is a display language should be discouraged until there is some responsible independent body that has verified them as "secure".
There is a question of "trust" levels here. And in my experience I don't "trust" anything whose source code I have not reviewed or has not been reviewed by people whom I can trust. And that is simply not the case with most or all of the scripting languages currently available.
Thus their use should be discouraged.
Oh wait. That's now. But hey! At least they don't have to actually deploy web apps. That's progress!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You could use the JSON as message format with hidden iframes, too.
while (!asleep()) sheep++
I didn't see much on their site about the API, just the serialization, but I'm wondering how this compares with JPSPAN (http://jpspan.sourceforge.net/wiki/doku.php) which actually mimicks the server-side objects in JavaScript, which is a really cool idea that take a lot of the pain out of client-side RPC programming.
putfwd.com - 1GB Free file storage with a twist
This is good even for "static" pages (not reloaded/redrawn in response to interaction with a user). HTML is a badly designed presentation protocol, even (especially) after all the "dynamic" revisions. Just as you can embed an image with tags, or movies, or sounds, or other multimedia objects, you should be able to embed text or HTML with a simple tag with a "SRC" parameter. <OBJECT> and <IFRAME> tags bring a lot of overhead, and extra GUI features that prevent the embedded text from appearing in the page exactly the same as the text directly in the page's HTML. So these client/server objects can at least provide the functionality that browsers should have had since Mosaic. Too bad it can't just use the browser's own HTTP and rendering engine with a simple <CONTENT TYPE="text/plain" SRC="http://slashdot.org/~Doc%20Ruby"> tag pointing to an existing simple web page, but rather forces the downloading and running of Java and a menagerie of interfaces.
--
make install -not war
I'd like to ask how is it possible to get rid of that 'click' sound explorer makes when it reloads the frame. I couldn't ever solve this problem without a downloadable .reg file.
--Coder
A long time ago I realized the need for speedy updates to a web page without having to reload a page. Instead I created a very small Java class that could be loaded with the page and called via Javascript. All it does is call a web service and return the result. The javascript routine that made use of that class accepted two parameters: the URL to call and the DIV name to put the result in. It acted as a great hook for dynamically modifying any page without reloading the entire page. I was able to create some very sophisticated looking data pages that updated quickly.
The end result was fast, flexible, and did everything this stuff will do. So why would I switch?
To make use of a standard. There has been no good standard way to do what this does. I'm all for it, and I'll be diving in right away.
*** *** You're just jealous 'cause the voices talk to me... ***
Google is currently one of the masters of Javascript.
Look at what they have done, and what they have not done - GMail has a very good interface. But even Google has released some real applications, like desktop search and Picassa.
I really believe the browser model can only be taken so far. As someone else noted, your browser becomes your window manager and pretty soon you develop a little cosmos in there. But that cosmos will always be a subset of the richer cosmos the OS itself offers, and so web apps will be convienent but probably never dominant. There is too much to be gained by going to a desktop app.
What I think will happen instead is that hybrid desktop apps, where part of the UI is essentially JavaScript will emerge and the desktop part is able to do what it does well.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
JSON is not less secure than normal web access. Say you have a servlet mapped as such:
which allows you to delete theThe same is true for JSON. Sure you can expose a deleteFile() method, but it would be just as stupid as the above mentioned URL. You always have to add some security and you do that the same way regardless of wether a request comes in to a servlet which you write or via JSON.
The typical way to handle authentication is through the application servers login stuff which binds a principal to a session, or you do it by hand by using a ServletFiliter on top of the pages (and the JSON servlet).
I've been using this stuff for almost a year, even though the people at work were too short sighted to see the advantages. Then GMail came out and lo and behold, google was doing what I was doing. This is the way to make powerful web apps and lighten the burden of maintaining state. This is the future for at least the next five years in web development. Now that the cat is out of the bag, I guess I won't be so elite anymore. But if anyone wants a wizard on this topic, send me an email and I'll come work for you.
I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.
NeXTStep circa 1994 used to store defaults settings using property lists:
...
{} = dictionary, () = arrray
{ a = "First", b = "Second" }, etc.
Mac OS X switched to using XML format for them !
Try:
defaults read com.apple.mail
and
more ~/Library/Preferences/com.apple.mail.plist
(Look at this for example. 100kb script library and the client code using this API will look clumsy and not as descriptive as JSON code. The javascript-RPC client api I wrote is about 4051 bytes, the server part 5853 bytes without any size optimization.)
Not the DOM is the problem, the implementation of a the javascript DOM doesn't work well for this kind of problem.
IMHO the only reason to use XML in javascript is that you absolutely WANT to. There's really no need in using to travel a DOM or using XPath when you can use nicely nested javascript objects with descriptive members.
while (!asleep()) sheep++
I think I'll use this. I've dreaded to do it manually and this is just what I need.
Having done most of my web dev work for internal corp sites with IE as the standard, I fell in love with the XMLHttpRequest paradigm a long time ago. Basically you throw up a simple page with some controls and some DIVs. That page stays in the browser during the whole session. As the user interacts with the controls, you submit http requests for backend pages and paste the results into the DIVs, either as HTML or using an XSL transform. Or you use dynamic HTML to doctor individual elements with the results. One neat thing about doing it that way is that session state maintenance goes away. The page that stays in the browser maintains its own state information, just like a standalone client app.
.Net way of sending in the change, requerying and refreshing the whole grid, it's much faster to send in the update as an http request and use dynamic HTML to alter just that one row with the results.
I've been doing this in the IE world for about 5 years, and I thought it was the way Microsoft was going to push web apps in the future. Boy was I surprised when ASP.Net turned it completely around and said now the new cool thing is to make a trip to the server just about every time anything happens. What a waste!
I never heard any good reasons for going it this direction, and I still think dividing the work between the client and server is a good thing. One classic example is a large datagrid populated by a complex query, that allows the user to update individual rows. Rather than the
There are some tempting "simplifications" in JSON, most of which may cause trouble if deployment becomes widespread.
First, it's an RPC protocol, which means the client can call arbitrary functions on the server. This is always a potential security hole. Every function available on the server is effectively trusted. Expect attacks based on this. It's at least as vulnerable as CGI, but it's new, so new mistakes will be made. The most likely holes will involve not crashes, but the ability to make broader database queries than was intended, via "SQL scripting" type attacks. Resource exhaustion denial of service attacks by clients that make repeated calls is also a possibility.
Second, there's no versioning. This works fine as long as a new client is downloaded on each use. If it's possible to get the client out of sync with the server, something will break.
Third, error handling consists of closing the connection on any problem. This equates to one support call per problem.
This new protocol will become bloated like the others as those problems are fixed.
So that leaves the text. Which shouldn't be that large. And if its compressed in the transmission, it should be really small.
Hey, I'm just your average shit and piss factory.
YAML.org does about the same thing, though its goals are slightly different. XML is still a good idea -- in theory, Marge.
it's been in msie since 2000 or so. very handy. stable. probably a HUGE security hole like anything can be...
very good for writing dynamically browsable trees and things using selects and stuff.
i'm sorta shocked this is news and/or that there hasn't been a move to standardize this already.
m.
"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."
"Artsy" devlopers don't program in the raw to begin with. That's what front end tools are for.
Anyway "artsy" developers use stuff like this to get what they want. (programmed in XML and JS). There's even an Eclipse plugin to help. Maybe one of you non-"artsy" developers can mod it to spit out XUL?*
*And ditch HTTP for communications. Try Jabber.
Bring back the good old days! I love applications that only work on one platform. I need the speed that comes from undocumented OS calls, so when the app crashes it takes the system down with it. I think every app should have a totally different interface, because the developers know what users really want.
I love recompiling my applications every time a new OS version comes out. I really love writing my own make scripts because the developers don't package the app for my platform. And I'm ecstatic when my application uses some non-standard network ports, so I get to poke holes in my firewall. Undocumented network interfaces are thrilling as well, since they allow new ways to infect my computer with viruses. It fills me with joy when I get to maintain my own client-side data, allowing me to spend hours pretending to be an SA and hundreds of dollars on local storage.
Who wants boring old web apps that run on almost all OSes, over secure HTTP streams, on platforms (web browsers) maintained by hundreds of professionals, using web interface components used by web developers world-wide, and using data maintained by yet more professionals in real server rooms? This makes computing less of an adventure and more of a utility.
"(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)"
XML is not S-Expressions.
I'd actually turn that around. You understand that the system uses the same mechanisms as normal web access; however what is being done is application logic is being remoted. As such, in my opinion, security will have to be added on as an afterthought in many, if not most applications. While this is certainly feasible, it is not, in my opinion, a good thing.
And exposing application logic with no more security thant "normal web access" is a good thing?
And which, by default is what happens if you just remote your objects using JSON. What I'm saying is that this could be improved upon.
Now, the thing to remember JSON helpfully creates a session for you if you don't have on. So relying on the session to be created by your login page won't work, unless you have every object referenced by the JSON servlet check the session to make sure it is legit -- which is ugly. One of the nice things about JSON is that it allows you to remote access to POJOs, which in my book is a big plus. Right of the bat, you don't have your application logic littered with framework APIs that you may want to get rid of later.
Your ServletFiler idea is essentially the same as my suggesting that we could apply an AOP interceptor on method requests. It's a good idea, so far as it goes, but to my mind it could be improved upon by building the security right into the servlet. The entire point is to make accessing remote logic from DHTML easy and hassle (i.e. bookkeeping) free. Granted creating servlet filters would not be rocket science, but in many cases there would be important cases overlooked, especially after software maintenance adds APIs to the objects in question.
Let me give you an example of one possible way this could be done. I just pulled this out my hat, so it is far from perfect, but it illusrates how the process could be simplified.
Suppose every class has a properties file listing who is allowed to access each of its methods.
ping.deny:none
ping.allow:all
alist.deny:none
alist.allow:adminstrator,programmer
Now when a remote user tries to "Test.ping()", he gets the normal results. If a user tries to Test.alist(), his browser gets a 404 non-authorized, and he has to provide credentials if he hasn't done so yet.
Now, to simplify the bookkeeping, the servlet can use introspection to create and maintain these properties files. When it sees a new method that isn't in the properties file, it can add the method to its security properties, defaulting to deny/all allow/none, the default policies to be settable by the servlet properties. When you are almost ready to deploy and have thoroughly unit tested all your remote logic, you just edit up the securities properties and run your user tests and you have a reasonably secure application.
Next add a few interfaces for authenticating roles and users, and a few simple ready made implementations, for example using the container's digest authentication mechanisms, and you've got a reasonable, simple, extensible and replaceable default starting point for security. If the interface didn't suit your particular needs, you could turn it all of with a servlet property and use whatever method you wanted to.
But you wouldn't start out of the gate with a completely unsecured application.
I should be clear here. I think JSON is impressively clean. However, I think that security should not be an afterthought: it's going to be a requirement in virtually every non-trivial application it is used in.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
What sort of validation is provided? Anyone can come up with a protocol that is thinner than XML, XML wasn't meant to be small. XML is readable while still allowing for type checking (basic with DTDs, advanced with Schemas or RelaxNG). Why pass around objects if you aren't going to do type-checking?
"I honestly would vote libertarian if their candidates weren't usually total cooks."--slashdot poster
I see some of the posts on here complaining about user interfaces via the web not being up to snuff, or the web not being 'suitable' or proper for certain things, or 'shouldnt be used' for task x. I hate to tell you, but the web can do a lot of things and if it works, it works, point blank. Want better UIs? Check out the XUL with firefox. My company has been doing the behind the scenes js calls for over 5 years now, this is nothing new. When we saw what they ff/xul guys were doing, we instantly realized they knew how to do it right from a developer's standpoint, and its first rate. For a little background, our progressions of js-callback tech went like this:
.asmx extension, and they are hailed as groundbreaking.)
. org/wiki/XUL_is_COOL
First we used a hidden background frame to pull in data behind the scenes, and process posts to the server, all managed by a multiple queue which handled all calls in an orderly fashion and async. less control than a socket, but it worked well in commercial apps. Then we moved to something like
this.oXmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
which gave us more control, but still wasnt cross platform. It could use xml, or just a variant of soap, or just text values, posting it to a ASP file. (And then MS makes something similar, calls it webservices with a asp file having a
And then we moved on to XUL + XMLHttpRequest
which is much the same as xmlhttp from ms, in fact when we ported over the IE6 specific js code, it worked almost flawlessly (the xul devs knew it was a 'good idea' and made sure they had a version in their stuff that matched the method sigs almost item for item). After we knew that the xul stuff was good under the hood, we had to know that the GUI-widgets was going to match our overly engineered 5000+ line dhtml controls (pain to write, but they sure look good.)
XUL blows this one out of the water.
intro
http://docs.mandragor.org/files/M isc/Mozilla_applications_en/
http://en.wikibooks
file explorer! (nice)
http://filemanager.mozdev.org/
svg dom + xul dom intertwined (ff 1.9?)
http://www.croczilla.com/svg/samples/
oh oh oh you say! but Avalon/XAML are coming! --- and I say yeah, its nice, and does the xml markup of guis with the code behind, same thing as XUL. And you can bet your bottom dollar MS is betting on that (and indigo, and <blah blah blah/> to force you into longhorn, as well as another upgrade cycle. Avalon is essentially the same thing as xul, but with 2d rendering done via DX on your 300 dollar gfx card.
So, since its getting late and I really should get off of this soapbox, the moral of the post is that the web can do more than you think, so give XUL a try.
In response to the parent, I've been doing this too, through iframes, Javascript and some server-side-scripting.
I keep a hidden iframe that handles all my db transactions. All forms post to that iframe. The server-side language (I use PHP), dynamically creates JavaScript that accesses objects in the main frame, and updates them. This way, I don't have to reload the whole page.
Vivin Suresh Paliath
http://vivin.net
I like
Java Script Object Notation is a native construct of JavaScript. As such JavaScript interpreters for parsing a JSON construct would be very highly refined requiring minimal resources from the host machine.
JSON parsing was written way before any XML parsing and would be compiled at a lower level since again it is a native construct.
Python would be the same.
There is a similar interface to serialize objects between PHP and Javascript called JPSpan (http://jpspan.sourceforge.net/).
In addition a toolkit I've been working with to assist developers building such Javascript/PHP applications can be found at http://www.qwad.com.au/framework/
Although the technology to do this has been around for a while, it's good to see people starting to realise some of the possibilities.
Java Script Object Notation is a native construct of JavaScript. As such JavaScript interpreters for parsing a JSON construct would be very highly refined requiring minimal resources from the host machine.
XML is a native document format of web browsers. As such, XML parsers are very highly refined requiring minimal resources from the host machine.
Javascript is a general-purpose scripting language, and as such, a parser is necessarily more complex than a parser for a format that simply represents data.
SON parsing was written way before any XML parsing and would be compiled at a lower level since again it is a native construct.
"Compiled at a lower level"? It sounds like you think the XML parser in web browsers is code that runs on top of the Javascript engine. You are wrong.
How secure is this? Haven't we seen enough havoc wrought with webpages that just go off and do what they want, instead of the web page viewer human actually selecting something? How many ActiveX and JS type security risks and exploits and "surprises" will it take to sink in? Is this lesson never to be learned, or what?
Ya this sort of dynamic stuff can be used for "good", but it also most likely will be exploited for teh evil, and everyone knows it too, and joe poor web surfer will *not* know if he's hit a good or evil website until AFTER he shows up on the webpage, when it's too late. Get it? A-F-T-E-R. As in "too late", hacked, owned, screwed again.
Just like now with JS and flash and whatnot. It's bogus 'sploit du juor, or screwy looking webpages with "style" sheets that *almost* work,(they can't even get that style sheet crap down so it actually works on most sites that use it) And know they want all sorts of new and shiny programs to be automagically activated when you click over on some site? Huh???
uh huh, I bet this is real secure. And no blackhats will ever abuse it.
You can run nitromethane in your car too,get some darn impressive spiffy street effects out of it, the deal is, do you *want* to all the time, is it really a good idea?
Not trying to rain on anyone's parade, but how about this, just for something to chew on. How about making the web you got to play with NOW secure (and accessible) FIRST before you make it even more possibly IN-secure and IN-accessible unless you have broadband and a multi GHz machine with a gigs of RAM and 16 virus programs and three firewalls and block this and non pop that and..phooie. Just to surf??
It's already annoying enough the amount of web pages you click over to INSIST you have images and JS turned on in order to use or view their site and the pages are obviously meant ONLY for people with wicked almost new fast machines and high speed broadband connections. You can't even get most webmasters to do a simple basic HTML 101 useability tiny pice of code typing which is to put alt text tags on images or image links anymore,it's become a lost art, they *don't freeking care*. It's not like they don't know about it, they absolutely don't care, can't be bothered with it, and I can hear them mumbling "&*&&^^^ them turkeys". Sorry, that's already quite rude enough. Now this stuff, they are gonna run all sorts of applications over the net? Click over and WHAM your machine starts doing whatever the heck some guy you never saw thinks it should be doing?
Say WHUT? Oh boy, I can just see it now....not
Good luckski, I'll be avoiding most of those pages whenever I run across them, just like I avoid JS and flash and cookies and images including web bugs now whenever possible. Man, just turning off JS and you avoid 90% of the bogus crap on the net. I kept wondering, like for the longest time where the hell all these "popups" were everyone was kvetching about, then one day I forgot and left JS on after I absolutely had to use it to get what I wanted at this site. MAN, the web is crawling with JS crap that popups ads and stuff! I didn't even know it! thought I was just lucky or something, turns out I took some security advice to heart and IT WORKED. And to avoid it, all I did was turn it OFF, didn't have to download install a new program or whatever. That should be a clue or two I would think.
I just don't see this "new shiny" automatic web applications to last more than a little while and it will primarily be used by the same slimy guys who write and deploy all the crap viruses, trojans, adware, spyware, keyloggers, blah blah blah out there now. And no, absolutely no, I do NOT trust anyone's "assurances" about how "safe and secure" it is. We see security bugs found every day in stuff written years ago and used by millions and they still keep appearing. I'm fed up with "new shiny" crap on the web. FIX what you have FIRST please before you go off and force more crap on us. I'd be much mo
"First: javascript is a shit language for anything other than DOM manipulation."
I think this sweeping statement needs some backup.
My suspicion is that anyone who believes this simply isn't fully aquainted with Javascript.
Unfortunatly our corp still has images floating around with IE 5.5 sp1 installed. It carries MSXML version 8.0.5226. Has anybody gotten JSON-RPC to work solidly on these versions of IE?
I'm having a bit of trouble tracking down a machine with it installed but I know it's out there.
Tnx
JsD
I use the hidden iFrame technique quite extensivly in an enterprise system and the code needed to make it work solidly is rather complex. Aside from complexity, the hidden iFrame also has issues with the user easily killing the submit/get of the iFrame. This killing of the iFrame must be detected or blocked by the code else the DHTML application fails and the user blames the developer (as expected).
:]
I have gotten around this by poping up a modal window with some eye candy to capture all refreshes, stops, hotkeys etc, while the hidden iFrame is being processed.
The advantage to this JSON-RPC methodology is that the code is completely synchronous. If you look at the source code, the request to the server and the response is on the same line. In the hidden iFrame, the event must be serialized and the loading of the iFrame must de-serialize that thread and continue the code. With JSON-RPC, you are on the next line of code.
Much, much simpler and faster.
Now hopefully, If I can get IE 5.5sp1 to work solidly, all my client side DHTML apps are going this way. Since I've been doing strong client side DHTML apps for years using hidden iframes as an RPC framework, I can turn JSON-RPC on in just a few days
Yes you are correct, JSON parsing is not a lower level than XML, however it is at least as efficient. Just look at the total number of bytes in a JSON data structure vs an XML data structure. The only way to make XML as efficient is to compile it in some form but I've never seen compiled XML or support for such frameworks. Just gzip and you can gzip JSON too.
I'd be surprised if JSON eval is slower than an XML parse.
Another beautiful advantage of JSON is that again it is a native JavaScript data structure. A JSON is an object is a hashmap...
It's the sweetest thing I have ever found in any language. Now if only I did'nt ignore that chapter when I was studying JavaScript way back when...
Here're my 2 cents worth: http://www.i-fidelity.net/
Waqui: Web Applications Quickly requires NO applets or plugins or XUL or Avalon. It is backend agnostic and is very light weight (200k). It is also pre-release so don't be too harsh.
Waqui is aimed at "distributed complex back-office applications". It uses a tiny XML protocol to communicate with PHP/Java/ASP/...
More examples coming soon...
Andy
Couple days late, but I just finished banging out a lightweight PHP implementation of JSON.