Because that leads to dependency hell, and that leads to horrible user experience.
Hurry, better tell Valve! And maybe Microsoft, too, while you're at it! Or Apple, for that matter -- they love frameworks, as long as it's one they shipped with the OS.
Seriously, Linux has solved this dependency issue with package managers for decades. Contrary to popular belief, it's trivial to support multiple versions of a library. And with the App Store, no one can claim installation as a problem -- the App Store can easily be thought of as a package manager that only supports the official Apple repository.
It's obvious why they don't want people using that API -- but not obvious why they don't just expose the API.
It's especially not obvious why apps created with PhoneGap were rejected, yet the exact same app, when you meticulously s/PhoneGap/Blargh/, were approved.
Because using application bundles avoids DLL hell.
There are other, more efficient ways to avoid DLL hell. And while that may make sense on a desktop, it seems truly moronic on a mobile platform, where space, bandwidth, and RAM are scarce.
They don't care if you use QT in your app.
Some of the rejection stories coming out suggest otherwise -- that they dislike any "external framework".
Javascript has eval yes, but the only way you can run javascript on your iphone is inside the web browser
Not true. Last I checked, you're allowed to use webkit (Javascript and all) as part of your app, and have it talk to native code, so long as none of the scripts are coming from the Internet.
Native apps on the other hand that run on the hardware itself are not allowed to eval
It's possible Apple is that stupid. But no, see above -- they just aren't allowed to eval things that have been downloaded/input.
You can't have a java VM/.NET.mono runtime
See, this makes no sense -- they already review apps like I described (webkit widgets) to ensure they don't eval anything from the Internet. Why not do the same to Java/Mono/etc?
if you compile your app+mono down to one executable, so the framework bit you can only run your app, that might be ok.
Except it isn't, always -- from the same article (which was on Slashdot)...
I chose to build my application on... PhoneGap.... You write your application in HTML and JavaScript.... While Apple doesn't explicitly forbid the use of PhoneGap, it's clear they reject many -- but not all -- projects that use it.... PhoneGap is an "external framework" and those are forbidden.... The men and women behind the curtain only look at the linking tables to see the names of the objects. So someone wrote a Python script that would replace the word "PhoneGap" with your own made-up package name. Voilà -- it often works.
So no, it seems doubtful that if you wrote an "external framework" that compiled Mono down to binary, that your app would be approved, at least unless you hide the fact that you used such a framework.
Isn't the iPhone is starting to sound like the most anti-developer environment ever?
Of course, Linux is not free either, unless the only cost you consider his original purchase price.
That's pretty much what I'm considering, here.
If your time is truly valuable, so that you can do other things besides futzing with your computer, get yourself a Mac.
I spent far more time futzing with my Mac to get it working the way I like than I do with KDE. And it still wasn't anywhere close to what I'm used to.
On the other hand, if you enjoy surfing the web for hours, trying to find that driver that will work under Linux, for that new really nice scanner with all those bells and whistles, then that is another story isn't it?
Where to begin?
I can't remember the last time I've used a scanner.
Digital cameras work fine. "Out-of-the-box" fine.
I've had exactly one Linux driver issue with this computer, and easily ten or more Windows driver issues.
Your stereotype isn't entirely unfounded, but it's getting a bit old and often dead wrong.
Regardless, I think the point stands. If I had a Linux computer -- or BSD, or Solaris, or Plan9, or Haiku, or OS 9, or Win2k, or anything except OS X or Windows XP+ -- then iTunes is not free, it's an expensive upgrade.
So, where'd your "it's free" argument go? You instead dropped to, "Oh, well, nothing's free." I think you've made my point for me.
They do not want third party apps using fourth party libraries using Nth party foo on their platform.
Uhm... Why not?
Code reuse and the deployment implementation are completely separate issues.
Except that they tend to avoid even apps which have had some of their code generated by a third-party tool, so it seems that "deployment implementation" or not, Apple's policy is effectively blocking some forms of code re-use, for no good reason.
VM that could allow people to run applications that haven't been blessed by Apple and sold through the iPhone App Store.
Except their own, of course. JavaScript has eval(), which does work on the iPhone, AFAIK. It's up to Apple to reject apps that use it to download code from the Internet.
So really, this is a complete bullshit argument.
I wouldn't want to waste my time developing anything for the iPhone given their approval policies.
Yes Mono Frameworks are a POS compared to Cocoa Frameworks. See how substantial your arguement is and how I counter with an equally weighted view? In this case, it's true,
Actually, no, it's not. As the AC says, Mono Touch wraps Cocoa anyway. This is about Apple not allowing people to build frameworks, even if said frameworks cooperate with their precious Cocoa.
It really looks like you're confusing an API with a language.
Bottom line, Cocoa Frameworks are unified down to the kernel. Mono would be a second-rate solution.
Actually, it looks like you don't know the difference between an API and a language. If you're the competition, maybe I should get into iPhone development, because damn.
I don't know that they do, but I do know that there was a specific framework -- can't remember the name, but one man's ebook was rejected when it was built in this framework, yet sometimes accepted when he hid the fact that he used the framework.
It isn't so much that they banned the framework explicitly, as that the use of this framework led to an app not being approved, yet the exact same app, once it had been scrubbed of obvious references to that framework (seriously, changing variable names), was approved. This has happened repeatedly.
Increasingly, most websites these days are browser gnostic,
I wonder what that would look like?
<pedantic>It's browser agnostic.</pedantic>
The first thing I do then is tell my Mac to lie to that website by telling it that Safari is now Internet Explorer under Windows, and 90% of the time it works just fine after that.
And the other 10% of the time?
That's a small taste of how "free" something like iTunes is. (Remember: OS X isn't free, Windows isn't free. Would you really recommend I try it under Wine?) Never mind the hassle of booting another OS, even in a VM, just to buy a fucking song -- much like you must be irritated by having to boot Windows in Parallels, or reboot with Boot Camp, just to view a website.
Of course, if you're like me, most of the time you won't bother.
That, or have the other person use another computer. It's not as if it'll be hard to install.
down that path lies "boop, boop, boop" when too many keys are held down.
Is this a limitation of the OS, the browser, or the hardware? I'm guessing the hardware, but that's just a guess.
you'll run into problems while waiting to push maps, meshes, and textures through a sub-1 Mbps connection.
See my other post.
And on a sub-1mbit connection, it still seems quite feasible to expect thirty seconds to a minute -- as good as some Flash games, or YouTube on slower connections (buffering). Still doesn't make it less cool on faster connections, or for smaller games. And certainly doesn't mean we shouldn't pursue it, when we all know bandwidth is expected to increase steadily.
Even when the interval gets down to 16.67 milliseconds (60 fps)?
Haven't tried, but you did specifically mention that you had this problem with long intervals.
But just for fun... I've now got a sample program working that uses between 15% and 40% CPU -- and that's out of 800 mhz (I'm on Linux, top measures vs current CPU, and since my laptop is mostly idle, it's clocked itself back to 800 mhz).
Granted, it's not a particularly complex program -- it's just a stupid little drawing app, you know, draw lines to follow the mouse -- but the actual drawing method is called every tick, and it ticks at 16 ms. Just to confirm that this is happening, I had it increment a counter, wrote something else on an interval of 1000 ms (and had it check itself against wall time), and I'm getting about 62 frames per second. Sometimes 63, sometimes 61, never less than 60.
Oh -- and I'm on the Chromium nightlies. Wouldn't be surprised if some other browsers aren't quite as fast with Javascript yet.
I request a sound, and it plays three seconds later.
Is that true even when the sound is already there? (Example: data urls?)
More files == more HTTP requests
Only if you don't know how to concatenate them together for production.
one for each file == more startup time,
Only if the browser doesn't know how to make multiple requests at once.
Test-driven development just moves all the bugs to the automated test suite.
Since the automated test suite is a description of what should happen, and what it means for the program to work, you're basically talking about moving all of the bugs to the spec level.
And you know what? I'm fine with that. It absolutely is a definite improvement. And this is ignoring things ilke git-bisect, which rely on some sort of automated test -- it's difficult to communicate just how useful that is until you've used it.
Would you rather have the game freeze for three seconds every three seconds to load a resource?
Hmm, I don't remember Halo 2 using that, yet it streamed off a DVD. The maximum throughput of the Xbox DVD drive is 6.6 MB/s -- my Internet can do that, and I doubt Halo used anywhere near all of that, especially as they wanted to stream reliably.
Just offhand, I'd guess they prefetched things, asynchronously. Remember what AJAX stands for? That's right, asynchronous. I'm kind of surprised you suggested doing it synchronously.
The worst effect was "popup" or something like that, where the level of detail would adjust itself jarringly as things got farther away -- which is really more about the graphical capabilities of the system, and less about the fact that things happened to be streamed rather than completely precached.
O3D does indeed use either D3D or GL depending on platform. O3D is slightly higher level yes, but not dramatically so
Yeah, I get it about shaders, but "D3D or GL depending on platform" is pretty dramatic, at least for Windows users -- WebGL is likely to be slow with AeroGlass enabled, right?
There is, however, an IE plug-in for generic audio and video -- that's object/embed, with a straight mpeg, wmv, or something else readable.
Sixty percent of browsers are IE.
Sixty percent of users use IE. That's a meaningful distinction -- it's much easier to get those 60% to migrate to something else, than it would be to fix 60% of the kinds of browsers out there.
Unless the old system has Windows-only hardware.
The older the system, the less likely this is to be true. And even in cases where it is true, it is again a case where a geek could keep a clean Windows install running smoothly, whereas an ordinary user would decide it's "too slow" and just throw money at the problem.
Flashblock blocks SWF and only SWF. Its user interface is more focused than that of, say, noscript.
It seems very likely that something similar would appear for WebGL, or more generally, for Canvas-style elements.
I think grandparent's point is that a new API will likely not be "properly sandboxed" from day one.
In other words, it will be properly sandboxed later.
I can stand the growing pains, knowing it leads to a much better platform than we have right now. Right now, there are holes in our procedure -- I mean, I'm not even sure The Power of Paint saves a config file, let alone savegames, yet in the current model, it has write access to my entire hard drive, not to mention running programs. That has to stop.
Malware authors would love to prove you wrong.
I'm sure they would -- but I suspect they'd prove me right, by exploiting the drivers.
Which, by the way, really need to be fixed anyway. The way things are today, I should be able to download a game demo, or just a cool game, and install/run it as an unprivileged user. If there's a hole in the driver, I can't reasonably expect to do that.
It takes time to download the JavaScript, maps, meshes, and textures. This isn't any faster just because your game is in JavaScript.
It's true, Javascript isn't the reason -- though it could be part of the reason.
First, let's consider an extreme: Procedural generation. There exists a first person shooter which fits into 96 kilobytes. It's not instant, as it has to do the generation -- but there's also the part where you'd have to download it, run it, click "yes" to the security prompt, etc etc -- as you should, since it actually is a security hazard.
Now, consider that games have gotten fairly good at streaming game content. You can play all the way through Halo 2, or Jak and Daxter, without having to see a single loading screen.
So the only latency here are, not all the maps, meshes, and textures, but just enough to draw what the player can see at the beginning. The rest can be streamed on demand.
And before you say "too much bandwidth", it's probably a lot less than streaming HD video, which is something else some of us can already do.
Now, you could do this with a downloaded game -- and indeed, Steam does this with the original Half-Life (though it doesn't seem to work for any of their other games) -- that is, download a tiny downloader, then stream the game as needed. But here, there's still a ton more setup that has to be done than just clicking a link in the browser -- and this is a poor example, as Steam stops downloading while you play, waiting until you change levels.
And you're still dealing with both trusting a random file from the Internet, and reinventing the wheel -- the browser already knows how to cache things, and how to relate several resources by URIs, and these things together mean it also knows how to auto-update -- basically everything Steam does is a natural property of browsers and webpages. That's another cool feature for the user, t
I don't know, how does Google Voice hurt Apple? How does Java hurt Apple?
I mean, you can sort of come up with a rationale, but it's really, really strained. Basically, it's not about whether it directly hurts apple, as whether it might hurt Apple, and/or whether it lets Apple give up even a tiny iota of control over their platform, and/or whether it hurts Apple's partners.
In this case, it's probably about control. Apple is going to be very wary of any language which supports eval(), since that means my app could just download new code from the Internet and eval it, thus eliminating the middleman (bottleneck!) that is the Apple approval process for all future updates.
Actually, there are two large things standing in the way of that:
The best.NET development tool, from what I can tell, is still going to be some form of Visual Studio.
Unlike Java,.NET makes native bindings dirt simple. If you were using a DLL in C++, you can use the same DLL in C# relatively easily.
#1 means that even if people want to target Mono, they might develop in VS.NET anyway, which is a bunch of VS.NET and Windows sales for Microsoft. #2 means that anyone who doesn't deliberately target Mono is probably going to call a bunch of native win32 code, just because it's so trivially easy to do so.
Note that both of these exist even with a "100% compatible" Mono, unless it was also combined with a 100% compatible Wine, and we all know exactly how likely the latter is.
But the problem is, Apple has explicitly disallowed "frameworks" -- and this definitely sounds like a framework.
Which is another way of saying, Apple is strongly discouraging if not outright banning one of the best ways to re-use code. Can anyone tell me why Apple is against code re-use on the iPhone?
Yes... key word there: a plug-in. The Quake Live model is one plugin per game. The O3D plugin is one plugin for anything you might ever want to do with 3D.
I know so much that there aren't any readers for 3D models which makes the development of games very hard.
Somehow, I doubt it. The difference is that O3D seems to be putting that inside the plugin, whereas WebGL would require it on the server or in Javascript.
You have to program everything. No shaders, no phyiscs etc.
Yes, you have to program shaders -- just like you do with OpenGL outside the browser.
So basically what you're telling me is that O3D is easier, because it's got a bunch of stuff built-in that you'd have to add with WebGL. On the other hand, WebGL is going to be a lot easier to get into browsers, since about all they have to do is wrap OpenGL -- everything else, they're relying on the web developers to handle.
Slashdot Mirror
Because that leads to dependency hell, and that leads to horrible user experience.
Hurry, better tell Valve! And maybe Microsoft, too, while you're at it! Or Apple, for that matter -- they love frameworks, as long as it's one they shipped with the OS.
Seriously, Linux has solved this dependency issue with package managers for decades. Contrary to popular belief, it's trivial to support multiple versions of a library. And with the App Store, no one can claim installation as a problem -- the App Store can easily be thought of as a package manager that only supports the official Apple repository.
It should be obvious why Apple doesn't want that.
It's obvious why they don't want people using that API -- but not obvious why they don't just expose the API.
It's especially not obvious why apps created with PhoneGap were rejected, yet the exact same app, when you meticulously s/PhoneGap/Blargh/, were approved.
Because using application bundles avoids DLL hell.
There are other, more efficient ways to avoid DLL hell. And while that may make sense on a desktop, it seems truly moronic on a mobile platform, where space, bandwidth, and RAM are scarce.
They don't care if you use QT in your app.
Some of the rejection stories coming out suggest otherwise -- that they dislike any "external framework".
Javascript has eval yes, but the only way you can run javascript on your iphone is inside the web browser
Not true. Last I checked, you're allowed to use webkit (Javascript and all) as part of your app, and have it talk to native code, so long as none of the scripts are coming from the Internet.
Native apps on the other hand that run on the hardware itself are not allowed to eval
It's possible Apple is that stupid. But no, see above -- they just aren't allowed to eval things that have been downloaded/input.
You can't have a java VM/.NET.mono runtime
See, this makes no sense -- they already review apps like I described (webkit widgets) to ensure they don't eval anything from the Internet. Why not do the same to Java/Mono/etc?
if you compile your app+mono down to one executable, so the framework bit you can only run your app, that might be ok.
Except it isn't, always -- from the same article (which was on Slashdot)...
Ok, I finally went and found that article:
I chose to build my application on... PhoneGap.... You write your application in HTML and JavaScript.... While Apple doesn't explicitly forbid the use of PhoneGap, it's clear they reject many -- but not all -- projects that use it.... PhoneGap is an "external framework" and those are forbidden.... The men and women behind the curtain only look at the linking tables to see the names of the objects. So someone wrote a Python script that would replace the word "PhoneGap" with your own made-up package name. Voilà -- it often works.
So no, it seems doubtful that if you wrote an "external framework" that compiled Mono down to binary, that your app would be approved, at least unless you hide the fact that you used such a framework.
Isn't the iPhone is starting to sound like the most anti-developer environment ever?
half-assed ports
And why does another implementation language automatically imply half-assed ports?
Your ignorance is showing.
Of course, Linux is not free either, unless the only cost you consider his original purchase price.
That's pretty much what I'm considering, here.
If your time is truly valuable, so that you can do other things besides futzing with your computer, get yourself a Mac.
I spent far more time futzing with my Mac to get it working the way I like than I do with KDE. And it still wasn't anywhere close to what I'm used to.
On the other hand, if you enjoy surfing the web for hours, trying to find that driver that will work under Linux, for that new really nice scanner with all those bells and whistles, then that is another story isn't it?
Where to begin?
Your stereotype isn't entirely unfounded, but it's getting a bit old and often dead wrong.
Regardless, I think the point stands. If I had a Linux computer -- or BSD, or Solaris, or Plan9, or Haiku, or OS 9, or Win2k, or anything except OS X or Windows XP+ -- then iTunes is not free, it's an expensive upgrade.
So, where'd your "it's free" argument go? You instead dropped to, "Oh, well, nothing's free." I think you've made my point for me.
well java, and flash on other phones cut battery life by 1/3 or more.
And Javascript doesn't?
Apples' native apps already cut battery life down.
...so your point is?
not to mention horrible load times.
Let's actually try some apps and see if that's true. I doubt it.
It hurts Apples partners and customers.
Ok, I'll bite. How does it hurt customers?
The telcos ability to use the same device to sell various upgrades and data plans, mins ect.
Um... What?
Data seems to be much more expensive than minutes.
Your role as a consumer is to link your bank account to a regional telco and enjoy.
I don't see how this is improved by letting said telco lock down my phone, or lock me into a two-year contract.
Java might just eat into battery life just enough to on average change the device from "lasts a long time on a change" to "the battery life is ok".
...and Javascript doesn't?
They do not want third party apps using fourth party libraries using Nth party foo on their platform.
Uhm... Why not?
Code reuse and the deployment implementation are completely separate issues.
Except that they tend to avoid even apps which have had some of their code generated by a third-party tool, so it seems that "deployment implementation" or not, Apple's policy is effectively blocking some forms of code re-use, for no good reason.
VM that could allow people to run applications that haven't been blessed by Apple and sold through the iPhone App Store.
Except their own, of course. JavaScript has eval(), which does work on the iPhone, AFAIK. It's up to Apple to reject apps that use it to download code from the Internet.
So really, this is a complete bullshit argument.
I wouldn't want to waste my time developing anything for the iPhone given their approval policies.
Agreed.
That is not an advantage.
Yes it is.
Or do you want to have an actual discussion? Why isn't it an advantage?
Go native, or don't bother.
Why?
Yes Mono Frameworks are a POS compared to Cocoa Frameworks. See how substantial your arguement is and how I counter with an equally weighted view? In this case, it's true,
Actually, no, it's not. As the AC says, Mono Touch wraps Cocoa anyway. This is about Apple not allowing people to build frameworks, even if said frameworks cooperate with their precious Cocoa.
It really looks like you're confusing an API with a language.
Bottom line, Cocoa Frameworks are unified down to the kernel. Mono would be a second-rate solution.
Actually, it looks like you don't know the difference between an API and a language. If you're the competition, maybe I should get into iPhone development, because damn.
In other words, it discourages any kind of preprocessor. Nice.
I don't know that they do, but I do know that there was a specific framework -- can't remember the name, but one man's ebook was rejected when it was built in this framework, yet sometimes accepted when he hid the fact that he used the framework.
It isn't so much that they banned the framework explicitly, as that the use of this framework led to an app not being approved, yet the exact same app, once it had been scrubbed of obvious references to that framework (seriously, changing variable names), was approved. This has happened repeatedly.
Because they don't just want crappy ports of crappy applications.
Seems to me that discouraging code reuse is a great way to get lots of crappy applications reinventing the wheel.
Increasingly, most websites these days are browser gnostic,
I wonder what that would look like?
<pedantic>It's browser agnostic.</pedantic>
The first thing I do then is tell my Mac to lie to that website by telling it that Safari is now Internet Explorer under Windows, and 90% of the time it works just fine after that.
And the other 10% of the time?
That's a small taste of how "free" something like iTunes is. (Remember: OS X isn't free, Windows isn't free. Would you really recommend I try it under Wine?) Never mind the hassle of booting another OS, even in a VM, just to buy a fucking song -- much like you must be irritated by having to boot Windows in Parallels, or reboot with Boot Camp, just to view a website.
Of course, if you're like me, most of the time you won't bother.
Otherwise, two players have to share a keyboard,
So plug two of them in? USB keyboards are cheap.
That, or have the other person use another computer. It's not as if it'll be hard to install.
down that path lies "boop, boop, boop" when too many keys are held down.
Is this a limitation of the OS, the browser, or the hardware? I'm guessing the hardware, but that's just a guess.
you'll run into problems while waiting to push maps, meshes, and textures through a sub-1 Mbps connection.
See my other post.
And on a sub-1mbit connection, it still seems quite feasible to expect thirty seconds to a minute -- as good as some Flash games, or YouTube on slower connections (buffering). Still doesn't make it less cool on faster connections, or for smaller games. And certainly doesn't mean we shouldn't pursue it, when we all know bandwidth is expected to increase steadily.
Even when the interval gets down to 16.67 milliseconds (60 fps)?
Haven't tried, but you did specifically mention that you had this problem with long intervals.
But just for fun... I've now got a sample program working that uses between 15% and 40% CPU -- and that's out of 800 mhz (I'm on Linux, top measures vs current CPU, and since my laptop is mostly idle, it's clocked itself back to 800 mhz).
Granted, it's not a particularly complex program -- it's just a stupid little drawing app, you know, draw lines to follow the mouse -- but the actual drawing method is called every tick, and it ticks at 16 ms. Just to confirm that this is happening, I had it increment a counter, wrote something else on an interval of 1000 ms (and had it check itself against wall time), and I'm getting about 62 frames per second. Sometimes 63, sometimes 61, never less than 60.
Oh -- and I'm on the Chromium nightlies. Wouldn't be surprised if some other browsers aren't quite as fast with Javascript yet.
I request a sound, and it plays three seconds later.
Is that true even when the sound is already there? (Example: data urls?)
More files == more HTTP requests
Only if you don't know how to concatenate them together for production.
one for each file == more startup time,
Only if the browser doesn't know how to make multiple requests at once.
Test-driven development just moves all the bugs to the automated test suite.
Since the automated test suite is a description of what should happen, and what it means for the program to work, you're basically talking about moving all of the bugs to the spec level.
And you know what? I'm fine with that. It absolutely is a definite improvement. And this is ignoring things ilke git-bisect, which rely on some sort of automated test -- it's difficult to communicate just how useful that is until you've used it.
Would you rather have the game freeze for three seconds every three seconds to load a resource?
Hmm, I don't remember Halo 2 using that, yet it streamed off a DVD. The maximum throughput of the Xbox DVD drive is 6.6 MB/s -- my Internet can do that, and I doubt Halo used anywhere near all of that, especially as they wanted to stream reliably.
Just offhand, I'd guess they prefetched things, asynchronously. Remember what AJAX stands for? That's right, asynchronous. I'm kind of surprised you suggested doing it synchronously.
The worst effect was "popup" or something like that, where the level of detail would adjust itself jarringly as things got farther away -- which is really more about the graphical capabilities of the system, and less about the fact that things happened to be streamed rather than completely precached.
O3D does indeed use either D3D or GL depending on platform. O3D is slightly higher level yes, but not dramatically so
Yeah, I get it about shaders, but "D3D or GL depending on platform" is pretty dramatic, at least for Windows users -- WebGL is likely to be slow with AeroGlass enabled, right?
nonexistent IE plug-in for the element.
There is, however, an IE plug-in for generic audio and video -- that's object/embed, with a straight mpeg, wmv, or something else readable.
Sixty percent of browsers are IE.
Sixty percent of users use IE. That's a meaningful distinction -- it's much easier to get those 60% to migrate to something else, than it would be to fix 60% of the kinds of browsers out there.
Unless the old system has Windows-only hardware.
The older the system, the less likely this is to be true. And even in cases where it is true, it is again a case where a geek could keep a clean Windows install running smoothly, whereas an ordinary user would decide it's "too slow" and just throw money at the problem.
Flashblock blocks SWF and only SWF. Its user interface is more focused than that of, say, noscript.
It seems very likely that something similar would appear for WebGL, or more generally, for Canvas-style elements.
I think grandparent's point is that a new API will likely not be "properly sandboxed" from day one.
In other words, it will be properly sandboxed later.
I can stand the growing pains, knowing it leads to a much better platform than we have right now. Right now, there are holes in our procedure -- I mean, I'm not even sure The Power of Paint saves a config file, let alone savegames, yet in the current model, it has write access to my entire hard drive, not to mention running programs. That has to stop.
Malware authors would love to prove you wrong.
I'm sure they would -- but I suspect they'd prove me right, by exploiting the drivers.
Which, by the way, really need to be fixed anyway. The way things are today, I should be able to download a game demo, or just a cool game, and install/run it as an unprivileged user. If there's a hole in the driver, I can't reasonably expect to do that.
It takes time to download the JavaScript, maps, meshes, and textures. This isn't any faster just because your game is in JavaScript.
It's true, Javascript isn't the reason -- though it could be part of the reason.
First, let's consider an extreme: Procedural generation. There exists a first person shooter which fits into 96 kilobytes. It's not instant, as it has to do the generation -- but there's also the part where you'd have to download it, run it, click "yes" to the security prompt, etc etc -- as you should, since it actually is a security hazard.
Now, consider that games have gotten fairly good at streaming game content. You can play all the way through Halo 2, or Jak and Daxter, without having to see a single loading screen.
So the only latency here are, not all the maps, meshes, and textures, but just enough to draw what the player can see at the beginning. The rest can be streamed on demand.
And before you say "too much bandwidth", it's probably a lot less than streaming HD video, which is something else some of us can already do.
Now, you could do this with a downloaded game -- and indeed, Steam does this with the original Half-Life (though it doesn't seem to work for any of their other games) -- that is, download a tiny downloader, then stream the game as needed. But here, there's still a ton more setup that has to be done than just clicking a link in the browser -- and this is a poor example, as Steam stops downloading while you play, waiting until you change levels.
And you're still dealing with both trusting a random file from the Internet, and reinventing the wheel -- the browser already knows how to cache things, and how to relate several resources by URIs, and these things together mean it also knows how to auto-update -- basically everything Steam does is a natural property of browsers and webpages. That's another cool feature for the user, t
until browsers expose an API letting a JavaScript program read from USB gamepads, it won't work for other genres.
So it'll be proved with the genres that it works with, and browsers will expose a gamepad API once it's obvious that this is something we want.
Good point, though.
How does this hurt Apple?
I don't know, how does Google Voice hurt Apple? How does Java hurt Apple?
I mean, you can sort of come up with a rationale, but it's really, really strained. Basically, it's not about whether it directly hurts apple, as whether it might hurt Apple, and/or whether it lets Apple give up even a tiny iota of control over their platform, and/or whether it hurts Apple's partners.
In this case, it's probably about control. Apple is going to be very wary of any language which supports eval(), since that means my app could just download new code from the Internet and eval it, thus eliminating the middleman (bottleneck!) that is the Apple approval process for all future updates.
Actually, there are two large things standing in the way of that:
#1 means that even if people want to target Mono, they might develop in VS.NET anyway, which is a bunch of VS.NET and Windows sales for Microsoft. #2 means that anyone who doesn't deliberately target Mono is probably going to call a bunch of native win32 code, just because it's so trivially easy to do so.
Note that both of these exist even with a "100% compatible" Mono, unless it was also combined with a 100% compatible Wine, and we all know exactly how likely the latter is.
As the AC says, so does gcj.
But the problem is, Apple has explicitly disallowed "frameworks" -- and this definitely sounds like a framework.
Which is another way of saying, Apple is strongly discouraging if not outright banning one of the best ways to re-use code. Can anyone tell me why Apple is against code re-use on the iPhone?
O3D still uses a plug-in.
Yes... key word there: a plug-in. The Quake Live model is one plugin per game. The O3D plugin is one plugin for anything you might ever want to do with 3D.
I know so much that there aren't any readers for 3D models which makes the development of games very hard.
Somehow, I doubt it. The difference is that O3D seems to be putting that inside the plugin, whereas WebGL would require it on the server or in Javascript.
You have to program everything. No shaders, no phyiscs etc.
Yes, you have to program shaders -- just like you do with OpenGL outside the browser.
So basically what you're telling me is that O3D is easier, because it's got a bunch of stuff built-in that you'd have to add with WebGL. On the other hand, WebGL is going to be a lot easier to get into browsers, since about all they have to do is wrap OpenGL -- everything else, they're relying on the web developers to handle.