I guess if there is a man in the middle attack, malicious code could be put into the page anyway via a script tag. So there is no guarantee that the set of code that can run during your program's execution is exactly equivalent to your program's source code.
In that sense, just using eval against your own XMLHTTPRequests is no less safe than presenting a plain HTML page. As long as you validate the contents of your JSON objects on the server side before returning them back to the page.
I've been writing XML based ajax apps for some time now, but I understand the appeal of JSON.
It's not the smaller document size. The standard XML header is only about 35 bytes and you can make your tags as small as you like.
It's not the speed of parsing. The XML DOM parsing is done natively and quickly using xmlHttpRequest.responseXML.documentElement.
I think the appeal is the easy of getting started with development. With an XML DOM you can use or build an API to handle the client side traversal of the DOM to get at the elements your page is interested in. Or you can manually iterate through the DOM elements in javascript looking for what you want. With json, your objects are there ready to use in javascript in the structure that you built on the server.
I was one of those people saying it wouldn't be enough. And I still do think it's not enough for some things.
Making a 3D game and using hardware openGL acceleration is tough to do in with HTML5:)
I just meant that it's a nice option to have to build some applications. It also allows to make things somewhat cross platform with PhoneGap ( http://phonegap.com/ ) because things like GPS and motion sensors are already abstracted and the implementation to another webkit device wouldn't be difficult.
"Why would you comment when you obviously have no understanding of what the company in the story produces?"
I guess you didn't noticed that is more of a question than a comment.
"It doesn't make sense to use Android, and have to pay licensing on a product that they don't own when they have been around long enough to know what works and what their customers want."
Huh? Pay licensing for what? The platform Android is open source.
The eval is only as insecure as the host it's coming from. If you don't trust the source of the script/objects, don't use that source. And all http technologies are subject to man in the middle attacks, but you can always use httpS to help to mitigate that.
Depends on if you're including json as a script tag with the source to a host different than the one that loaded the original document or if you're retrieving json from an XMLHTTPRequest. The latter is sandboxed to the original document's host.
If they're a hardware vendor, why not just use Android?
Wrapping webkit and giving javascript APIs to talk to the hardware isn't a bad idea and it's working for PhoneGap. I just don't know why they have to re-invent the wheel.
Do they intend on making money licensing their WebOS to other hardware manufacturers?
The Filesystem of the guest machine is irrelevant to the host.
The host can use small(2GB) chunks and tell the guest that it is one big drive. The guest OS can then format that into NTFS or whatever and store large files.
So says the guy that just posted to a slashdot thread. If slashdot.org was just a static document with links, you wouldn't have been able to send your message back to the slashdot database for other's to read.
So one repo doesn't want to include something that could potentially get them into trouble. They reserve the right to do so.
Livna's repo is ok with providing that rpm. Just click on a link to the repo's definition rpm, and a GUI installer will popup asking you if you want to install it. Next time you run the GUI to lookup software Livna's packages will be included.
It's at least as easy as installing some unlicensed patent-encumbered piece of software on any other operating system.
Re:But does it run on .... shit that does not work
on
Fedora 10 Released
·
· Score: 1
And it's also hate based on yum's early implementations. It really has gotten much faster.
One thing that they did a few fedora versions back is switch from xml based meta data to gzipped sqllite files. Sped things up immensely.
I guess some people just like to criticize whatever it is that competes with the thing they're using.
This has been working 64bit openjdk for some time.
Though not the official plugin, the gcjwebplugin launches the 64bit JVM just fine.
Not sure which distro you're using but on fedora the package you want is java-1.6.0-openjdk-plugin which contains gcjwebplugin.so This is compiled for x86_64 and has no trouble running applets in 64bit firefox.
Well, I went and bought it on release based on their previous track record and their promise of a Linux port.
I have a useless 60 dollar box with a year's worth of dust on it. Their lie cost me a tank of gas.
You live you learn, I guess. Though it would be nice to at least hear them officially say they won't release Ryan's port because they're in bed with Microsoft.
You don't have to use those attributes. Things like djconfig on the script element is a convenience. You can still specify everything you need to in the script.
Don't think of dojo as just a collection of scripts for widgets or animations like in scriptaculous.
Dojo is a HUGE library that gives you the ability to pick bits and pieces where they might be helpful and in a way that hides some of the uglier browser-specific things that you don't want to deal with.
For example, using connect() to add an onclick to a DOM element will put some sanity to attributes of the mousevent object that gets passed. Sure I could write a bunch of code to get around the browser differences myself, but it's pointless when there's a free library like this to do it for me.
Why? Sharpdevelop is still locking you into windows for an operating system.
I don't know that I'd call Monodevelop a good IDE. It's a fork of an early version of Sharpdevelop, not a port.
By contrast, everything that I can do in Eclipse I for Windows I can do in Eclipse for Linux. The different ports have the same features and are released on the same day.
Slashdot Mirror
I guess if there is a man in the middle attack, malicious code could be put into the page anyway via a script tag. So there is no guarantee that the set of code that can run during your program's execution is exactly equivalent to your program's source code.
In that sense, just using eval against your own XMLHTTPRequests is no less safe than presenting a plain HTML page. As long as you validate the contents of your JSON objects on the server side before returning them back to the page.
Android is open source.
The parts that cost money are the proprietary hardware drivers and media codecs and things like that, but that's not free for any platform.
"While I don't see any appeal to JSON"...
I've been writing XML based ajax apps for some time now, but I understand the appeal of JSON.
It's not the smaller document size. The standard XML header is only about 35 bytes and you can make your tags as small as you like.
It's not the speed of parsing. The XML DOM parsing is done natively and quickly using xmlHttpRequest.responseXML.documentElement.
I think the appeal is the easy of getting started with development.
With an XML DOM you can use or build an API to handle the client side traversal of the DOM to get at the elements your page is interested in. Or you can manually iterate through the DOM elements in javascript looking for what you want.
With json, your objects are there ready to use in javascript in the structure that you built on the server.
I was one of those people saying it wouldn't be enough. And I still do think it's not enough for some things.
:)
Making a 3D game and using hardware openGL acceleration is tough to do in with HTML5
I just meant that it's a nice option to have to build some applications. It also allows to make things somewhat cross platform with PhoneGap ( http://phonegap.com/ ) because things like GPS and motion sensors are already abstracted and the implementation to another webkit device wouldn't be difficult.
"Why would you comment when you obviously have no understanding of what the company in the story produces?"
I guess you didn't noticed that is more of a question than a comment.
"It doesn't make sense to use Android, and have to pay licensing on a product that they don't own when they have been around long enough to know what works and what their customers want."
Huh? Pay licensing for what? The platform Android is open source.
The eval is only as insecure as the host it's coming from.
If you don't trust the source of the script/objects, don't use that source.
And all http technologies are subject to man in the middle attacks, but you can always use httpS to help to mitigate that.
Depends on if you're including json as a script tag with the source to a host different than the one that loaded the original document or if you're retrieving json from an XMLHTTPRequest. The latter is sandboxed to the original document's host.
Are these guys still making PDAs and phones?
If they're a hardware vendor, why not just use Android?
Wrapping webkit and giving javascript APIs to talk to the hardware isn't a bad idea and it's working for PhoneGap. I just don't know why they have to re-invent the wheel.
Do they intend on making money licensing their WebOS to other hardware manufacturers?
The Filesystem of the guest machine is irrelevant to the host.
The host can use small(2GB) chunks and tell the guest that it is one big drive. The guest OS can then format that into NTFS or whatever and store large files.
I thought it was implying that the PS4 is going to be low quality because it is using a low budget GPU from intel.
So says the guy that just posted to a slashdot thread. If slashdot.org was just a static document with links, you wouldn't have been able to send your message back to the slashdot database for other's to read.
You're right, Citrix has much better network performance than VNC.
I'd call FreeNX superior to citrix in that it is both free and has similar network performance to citrix.
And this has worked fine for the few applets I've run since being 64bit linux.
Still, it's nice to see the official version.
(lack of automatic boxing of primitive types anyone!).
The autoboxing/unboxing was included when Java 5 was released over 4 years ago.
And that particular syntactical sugar is nice, but was never a show stopper.
They shouldn't have shipped it at all then.
I've been developing in mostly java for over a decade and tend to agree with most of Sun's decisions, but this is weak.
If the product wasn't ready for all the target platforms than the product wasn't ready.
You've got to be kidding.
So one repo doesn't want to include something that could potentially get them into trouble. They reserve the right to do so.
Livna's repo is ok with providing that rpm. Just click on a link to the repo's definition rpm, and a GUI installer will popup asking you if you want to install it. Next time you run the GUI to lookup software Livna's packages will be included.
It's at least as easy as installing some unlicensed patent-encumbered piece of software on any other operating system.
And it's also hate based on yum's early implementations. It really has gotten much faster.
One thing that they did a few fedora versions back is switch from xml based meta data to gzipped sqllite files. Sped things up immensely.
I guess some people just like to criticize whatever it is that competes with the thing they're using.
oh, you just said you're on OpenSuse :)
No idea if there's a package in it's repo, but that's Suse's fault, not openJDK's or Sun's.
This has been working 64bit openjdk for some time.
Though not the official plugin, the gcjwebplugin launches the 64bit JVM just fine.
Not sure which distro you're using but on fedora the package you want is java-1.6.0-openjdk-plugin which contains gcjwebplugin.so
This is compiled for x86_64 and has no trouble running applets in 64bit firefox.
Yahoo owns Zimbra which can compete with exchange.
I'd hate to see microsoft buy yahoo just for that reason.
Well, I went and bought it on release based on their previous track record and their promise of a Linux port.
I have a useless 60 dollar box with a year's worth of dust on it. Their lie cost me a tank of gas.
You live you learn, I guess. Though it would be nice to at least hear them officially say they won't release Ryan's port because they're in bed with Microsoft.
You don't have to use those attributes. Things like djconfig on the script element is a convenience. You can still specify everything you need to in the script.
Couldn't disagree more.
Don't think of dojo as just a collection of scripts for widgets or animations like in scriptaculous.
Dojo is a HUGE library that gives you the ability to pick bits and pieces where they might be helpful and in a way that hides some of the uglier browser-specific things that you don't want to deal with.
For example, using connect() to add an onclick to a DOM element will put some sanity to attributes of the mousevent object that gets passed.
Sure I could write a bunch of code to get around the browser differences myself, but it's pointless when there's a free library like this to do it for me.
I haven't tried this out(not running windows), but how is this any closer to snowcrash than the 3D avatar chatrooms from 10 years ago?
If anything I'd say it's a step back since it's windows only.
How about making the Street from snowcrash an open protocol with multiple types of clients like 3D apps, 2D apps, AJAX, brew, J2ME, etc.
Why? Sharpdevelop is still locking you into windows for an operating system.
I don't know that I'd call Monodevelop a good IDE. It's a fork of an early version of Sharpdevelop, not a port.
By contrast, everything that I can do in Eclipse I for Windows I can do in Eclipse for Linux. The different ports have the same features and are released on the same day.