Sounds like you are the one guessing. I'm pretty sure they didn't ask for kernel access. All Adobe was asking for was the same capability as the Quicktime internet plugin, which has hardware accelerated decoding.
..it wasn't - Adobe was asking for the same full access to the kernel it has with the Windows implementation. Apple wasn't satisfied that Adobe code was up to the task of correctly handling that access and refused - told them to clean up the code and Adobe just shelved active development for the Mac. No guesses, the facts Jack!
There's no need to guess. The recent API addition for H.264 encoding is something Adobe has said they have wanted for awhile, but previously they didn't just ask for an API to effect those changes, they wanted direct kernel access, which Apple has refused to provide for good reason. Mac Flash is an extremely poor pile of code compared to the Windows version.
While this might be true, instead of whining about how they didn't get their hw video decoding on a silver platter from Apple, Adobe could also have invested in a generic gpu video decoding engine. For example based on GLSL or OpenCL. They didn't even have to develop one themselves, licensing one of the already available GLSL decoders was also an option. As an added bonus, this would bring GPU decoding to Linux as well...
Linux has had vdpau for nvidia for quite some time too by the way, and integrating it into Flash player should be trivial for adobe. I know XBMC had a full gpu decoding preview release within a week after vdpau beta's where released.
This all shows that Adobe isn't really that concerned with how well Flash runs on os x or Linux, if the development effort to make it right is higher than trivial, they make up some kind of excuse to put the blame anywhere else but their own incompetency. They stuck with carbon too long, they didn't transition to 64 bit on time, and they sat on their hands waiting for someone else to do their job to get hw video decoding in Flash player for Linux. It took them 4 years or something like that to get Flash 10 out, and still it is not feature complete on every platform, and there still is no 64-bit browser plugin. It really is a big pile of fail if you ask me.
What's going to be extremely interesting and entertaining is to see how Adobe will handle all the 100s of different hw combinations for their mobile player. Efficient use of every bit of hardware is even more important on mobile than on the desktop, and the effort to make it work right across every supported device is a lot higher. I can only imagine Adobe will fail even harder which will result in a terrible user experience on many devices, hopefully leading to the demise of flash on mobile. One thing I still don't understand why they even care, and if they're still so happy to have bought Macromedia in the first place. The development burden to keep Flash working will appears to be too much for Adobe, and I can hardly imaginer sales of their Flash dev tools make up for it.
What adobe should do is forget about Flash on mobile altogether and create a really,really good set of html5 dev tools instead. I think that would benefit everyone. Flash on the desktop they can keep around until html5 or whatever other technology is mature enough to replace it there as well.
I'll be surprised if this one resolves against Apple.
But I imagine constant investigations won't trend positive.
Apple does indeed have balls, and loves to walk the line.
The problem for the FCC and DoJ, is that they have already demonstrated with Microsoft how far you can go pushing anti-competitive laws. Apple is merely just scratching the surface in that regard.
Even if the DoJ sued Apple, it would be held up in the courts for 5 years, and Flash will be gone by then.
"Notwithstanding the foregoing, with Apple?s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application."
sorry, but the article kinda brushes over what seems to be the most important part. i am no lawyer, and thus i ask - "with Apple's prior written consent" - WHAT DOES THIS REALLY MEAN?
um, so, if i want to use unity after signing this agreement to develop on iOS 4, i have to email or write apple, and get a return document signed by someone at apple that says it is okay to use LUA or say javascript in the case of appcelerator maybe? seriously, what does this mean, "written consent"?
i mean, if it is what it sounds like, then the title of this article is totally off base. it shouldn't be, "apple to allow lua," it should be "apple might consider other things, on an individual case by case basis that will probably be less clear and more secretive than the process already is." no? i would like to be wrong here.
Since the Javascript Engine uses Lua I hardly thought they'd ban Lua.
This is just a natural extension.
That isn't true at all. There's no sense in which Webkit's JavaScript engine uses Lua. If you're basing that off this then read it more carefully. One of the Lua designers worked on Apple's JS engine, and they share some optimisation techniques, but that's all.
sorry, but the article kinda brushes over what seems to be the most important part. i am no lawyer, and thus i ask - "with Apple's prior written consent" - WHAT DOES THIS REALLY MEAN?
It is weasel-worded crap, designed to make it seem as if Apple has no intent to target Adobe.
Comments
Sounds like you are the one guessing. I'm pretty sure they didn't ask for kernel access. All Adobe was asking for was the same capability as the Quicktime internet plugin, which has hardware accelerated decoding.
..it wasn't - Adobe was asking for the same full access to the kernel it has with the Windows implementation. Apple wasn't satisfied that Adobe code was up to the task of correctly handling that access and refused - told them to clean up the code and Adobe just shelved active development for the Mac. No guesses, the facts Jack!
There's no need to guess. The recent API addition for H.264 encoding is something Adobe has said they have wanted for awhile, but previously they didn't just ask for an API to effect those changes, they wanted direct kernel access, which Apple has refused to provide for good reason. Mac Flash is an extremely poor pile of code compared to the Windows version.
While this might be true, instead of whining about how they didn't get their hw video decoding on a silver platter from Apple, Adobe could also have invested in a generic gpu video decoding engine. For example based on GLSL or OpenCL. They didn't even have to develop one themselves, licensing one of the already available GLSL decoders was also an option. As an added bonus, this would bring GPU decoding to Linux as well...
Linux has had vdpau for nvidia for quite some time too by the way, and integrating it into Flash player should be trivial for adobe. I know XBMC had a full gpu decoding preview release within a week after vdpau beta's where released.
This all shows that Adobe isn't really that concerned with how well Flash runs on os x or Linux, if the development effort to make it right is higher than trivial, they make up some kind of excuse to put the blame anywhere else but their own incompetency. They stuck with carbon too long, they didn't transition to 64 bit on time, and they sat on their hands waiting for someone else to do their job to get hw video decoding in Flash player for Linux. It took them 4 years or something like that to get Flash 10 out, and still it is not feature complete on every platform, and there still is no 64-bit browser plugin. It really is a big pile of fail if you ask me.
What's going to be extremely interesting and entertaining is to see how Adobe will handle all the 100s of different hw combinations for their mobile player. Efficient use of every bit of hardware is even more important on mobile than on the desktop, and the effort to make it work right across every supported device is a lot higher. I can only imagine Adobe will fail even harder which will result in a terrible user experience on many devices, hopefully leading to the demise of flash on mobile. One thing I still don't understand why they even care, and if they're still so happy to have bought Macromedia in the first place. The development burden to keep Flash working will appears to be too much for Adobe, and I can hardly imaginer sales of their Flash dev tools make up for it.
What adobe should do is forget about Flash on mobile altogether and create a really,really good set of html5 dev tools instead. I think that would benefit everyone. Flash on the desktop they can keep around until html5 or whatever other technology is mature enough to replace it there as well.
I'll be surprised if this one resolves against Apple.
But I imagine constant investigations won't trend positive.
Apple does indeed have balls, and loves to walk the line.
The problem for the FCC and DoJ, is that they have already demonstrated with Microsoft how far you can go pushing anti-competitive laws. Apple is merely just scratching the surface in that regard.
Even if the DoJ sued Apple, it would be held up in the courts for 5 years, and Flash will be gone by then.
"Notwithstanding the foregoing, with Apple?s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application."
sorry, but the article kinda brushes over what seems to be the most important part. i am no lawyer, and thus i ask - "with Apple's prior written consent" - WHAT DOES THIS REALLY MEAN?
um, so, if i want to use unity after signing this agreement to develop on iOS 4, i have to email or write apple, and get a return document signed by someone at apple that says it is okay to use LUA or say javascript in the case of appcelerator maybe? seriously, what does this mean, "written consent"?
i mean, if it is what it sounds like, then the title of this article is totally off base. it shouldn't be, "apple to allow lua," it should be "apple might consider other things, on an individual case by case basis that will probably be less clear and more secretive than the process already is." no? i would like to be wrong here.
Since the Javascript Engine uses Lua I hardly thought they'd ban Lua.
This is just a natural extension.
That isn't true at all. There's no sense in which Webkit's JavaScript engine uses Lua. If you're basing that off this then read it more carefully. One of the Lua designers worked on Apple's JS engine, and they share some optimisation techniques, but that's all.
sorry, but the article kinda brushes over what seems to be the most important part. i am no lawyer, and thus i ask - "with Apple's prior written consent" - WHAT DOES THIS REALLY MEAN?
It is weasel-worded crap, designed to make it seem as if Apple has no intent to target Adobe.
Apple has balls.
But the DOJ has a machete.
But Apple "knows the score" and "gets the women"
Borderline?
Yes. To say the least.