Also what the security concerned shouldn't forget is that no SSL support means you simply can't load SSL encrypted stuff it is not simply dissable and everything suddenly happens unencrypted. The full Opera mobile simply switches off the Turbo and does SSL pages like every other browser. Opera mini apparently simply does not load it at all.
The size saving are primarily gained through a rerendering of images in smaller size. Since most webpages are created to be watched on much higher res. than on an iphone the loss in picture quality is worth it.
The only reason Opera is making a big deal of creating and submitting this app, is because they know it will get rejected, and they just want the negative publicity once it does.
a) Bullshit. Please provide the SDK clause the expressly forbids all browsers....
b) A reason not to use it, not a reason to ban it. Want security? Use Safari or one of the other webkit based browsers ...
c) They are baiting Apple by trying to get their browser on the iPhone? Using that ridiculous logic, any company that submits an app that abides by the SDK could be defined as 'baiting Apple'...
a) That isn't what I wrote.
b) It should be clear to everyone by now that Apple isn't going to leave security on the iPhone to user discretion. It undermines both the user experience and trust to even allow users to use a browser that pretends to be secure but isn't. And it also undermines the user experience to have a browser that doesn't properly support the same on the iPhone, which Opera won't, which is why non-WebKit browsers shouldn't and probably won't be allowed.
b) It should be clear to everyone by now that Apple isn't going to leave security on the iPhone to user discretion. It undermines both the user experience and trust to even allow users to use a browser that pretends to be secure but isn't. And it also undermines the user experience to have a browser that doesn't properly support the same on the iPhone, which Opera won't, which is why non-WebKit browsers shouldn't and probably won't be allowed.
c) This response just doesn't make any sense.
You may now have the last word.
a) uh, yeah, it is.
Quote:
because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement
So, your claim is that you expect it will be rejected because "it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement". Pretty clear that is exactly what you wrote. You back it up, but there is no question that it is what you wrote.
b) and if the secure pages just don't load, then they are not leaving it to the users discretion.
c) Again, you wrote
Quote:
I'd be completely and utterly shocked if it were approved because [...] Opera are clearly baiting Apple
. i.e. By submitting it, they are baiting Apple. So, it should be banned because they submitted it. The responses makes perfect sense. The point it is a response to make none at all.
Could you explain how you see Opera as violating the quoted restriction?
Opera Mini does process compress data sent by Opera server. If the engine that process the compressed data is not native a Apple's API, which clearly it isn't, then it violates the previous SDK agreement clause.
Opera Mini does process compress data sent by Opera server. If the engine that process the compressed data is not native a Apple's API, which clearly it isn't, then it violates the previous SDK agreement clause.
You're not suggesting it's not possible to draw pictures using the standard APIs, are you? Because that pretty much how it comes across. To my best guess, this thing will be an app which receives a stream of data and represents it on a screen. Much like, say, an online game.
I am not buying it, his other argument about only webkit being allowed is understandable. But to say code is executed remotely, well, no, that happens in all servers.
Actually, the point wasn't that code was executed remotely, but that it was executed and/or interpreted without going through Apple's APIs -- in this case WebKit. Thus, a browser or web view using WebKit is fine, but one that doesn't isn't. Feel free to disagree, but do argue against what I actually said.
How come? It has not prevented its adoptions so far. Opera Mini gets about 4-5 million new active users each month. Opera has an excellent privacy track record, as a matter of fact.
You're not suggesting it's not possible to draw pictures using the standard APIs, are you? Because that pretty much how it comes across. To my best guess, this thing will be an app which receives a stream of data and represents it on a screen. Much like, say, an online game.
An online game are processed using Apple's Documented APIs and built-in interpreters to be displayed on screen.
I hope they allow it, but force them to call it something else besides a web browser.
It is a web browser.
Quote:
A technology with a huge downside to the consumer that Opera never talks about much and that the average consumer has no way of knowing about unless they are a techie.
Never talks about? Opera always talks about how they are compressing data before sending it to the phone.
Quote:
The more I think about it, Opera will probably refuse the idea that they have to put scary warnings on it and make it obvious to the end user how insecure the thing is
Opera Mini isn't insecure, and Opera Software has an excellent security and privacy track record.
And they are always bragging about how their server-side compression makes it insanely fast. You are claiming that they are trying to hide it, but that's just a lie.
Quote:
There are more reasons to dis-allow this based on consumer "expectation" and safety
The problem is that a browser engine provides a javascript runtime, and runtime environments are specifically banned by the iPhone developer agreement.
No pinch-to-zoom, and there *will* be page-rendering issues.
I use it on my E72, and have used it on my other Nokia devices. Outside of the pinch and zoom it works fine. I do not think, no I am sure you do not know what you are talking about. It uses SVG to format and render pages.
It is technically a web browser but one that operates in a significantly different manner from every other web browser and operates through proxy servers that the end user is essentially unaware of, and thus is a completely different animal. ....
fixed that for you.
Also, please look up "gainsaying," and find out how little it has to do with logic or argument.
Opera Mini does process compress data sent by Opera server. If the engine that process the compressed data is not native a Apple's API, which clearly it isn't, then it violates the previous SDK agreement clause.
Apple API does not do your work for you as a programmer. You are still expected to write the code, using the provided API when necessary. Opera could written their own decompression algorithm. That in and of itself is not a violation of the SDK, at least not the clause quoted.
How does a decompression engine violate this:
"An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s)."?
Any decompression will be built into the app, so it would't be launching (or installing) additional executable code. Decompressing a data stream is not the same as interpreting or executing additional code. If Opera's implementation does rely on interpreted code or launching additional executable code, outside of their app (not on a server), then yes, they are in violation. I just don't see how you can say decompressing data is in violation, simply by being decompression.
I think this is a slam-dunk rejection for violating the developer agreement and for undermining the iPhone user experience and security. Apple should just put this on the fast track, reject it, and be done with it, preferably by the end of the day. It's not like more than a handful of people care about Opera anyway, and it's not like it offers anything useful without also bringing huge downsides with it. ...
Anonymouse wins the thread! Yay!
Seriously, "Tulkas"??? you filled pages and pages of writing and I've read it all and you just don't have any argument against what anonymouse is saying. Nothing. Nada.
Anonymouse like all of us, could turn out to be wrong, but nothing you have said indicates that in any way. You are just being bitchy and harping about perceived details in conversations that didn't actually even happen the way you thought they did.
I don't claim to know for sure, but I think its safe to assume anything that leaves from, or arrives at your modem is pretty efficiently compressed already. And JPEGS etc. are already about as compressed as they can be without further loss. I would assume a compressed image of a web page would be more verbose than a compressed file of the HTML that describes that page. So I'm wondering where the gain is.
Is it just in making a choppier versions of web pages?
No, really you can gain a ton of speed by simply removing all the white space and line returns. For example all the big sites like Google and even the JS libraries are really compressed. It makes a huge difference. The code is no longer human readable but that is managed by maintaining a working version.
In the case of Opera their servers are compressing the regular html code. Average website code is not compressed at all. If you right click and view source that is what the browser sees. it doesn't uncompress any text. Opera is different with their iPhone browser, it will uncompress their specially encoded text as well as the photos.
Many web developers don't take the time to optimally compress or size their images either. Everything gets saved at quality 8 and then they often scale it in Dreamweaver which is totally slacker way of doing things. If a smart server can overcome these problems it makes sense to do it.
However the lack of https encryption in Opera mini is a deal breaker.
Comments
The size saving are primarily gained through a rerendering of images in smaller size. Since most webpages are created to be watched on much higher res. than on an iphone the loss in picture quality is worth it.
The only reason Opera is making a big deal of creating and submitting this app, is because they know it will get rejected, and they just want the negative publicity once it does.
Ok, let's look at post #39...
a) Bullshit. Please provide the SDK clause the expressly forbids all browsers....
b) A reason not to use it, not a reason to ban it. Want security? Use Safari or one of the other webkit based browsers ...
c) They are baiting Apple by trying to get their browser on the iPhone? Using that ridiculous logic, any company that submits an app that abides by the SDK could be defined as 'baiting Apple'...
a) That isn't what I wrote.
b) It should be clear to everyone by now that Apple isn't going to leave security on the iPhone to user discretion. It undermines both the user experience and trust to even allow users to use a browser that pretends to be secure but isn't. And it also undermines the user experience to have a browser that doesn't properly support the same on the iPhone, which Opera won't, which is why non-WebKit browsers shouldn't and probably won't be allowed.
c) This response just doesn't make any sense.
You may now have the last word.
a) That isn't what I wrote.
b) It should be clear to everyone by now that Apple isn't going to leave security on the iPhone to user discretion. It undermines both the user experience and trust to even allow users to use a browser that pretends to be secure but isn't. And it also undermines the user experience to have a browser that doesn't properly support the same on the iPhone, which Opera won't, which is why non-WebKit browsers shouldn't and probably won't be allowed.
c) This response just doesn't make any sense.
You may now have the last word.
a) uh, yeah, it is.
because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement
So, your claim is that you expect it will be rejected because "it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement". Pretty clear that is exactly what you wrote. You back it up, but there is no question that it is what you wrote.
b) and if the secure pages just don't load, then they are not leaving it to the users discretion.
c) Again, you wrote
I'd be completely and utterly shocked if it were approved because [...] Opera are clearly baiting Apple
. i.e. By submitting it, they are baiting Apple. So, it should be banned because they submitted it. The responses makes perfect sense. The point it is a response to make none at all.
Could you explain how you see Opera as violating the quoted restriction?
Opera Mini does process compress data sent by Opera server. If the engine that process the compressed data is not native a Apple's API, which clearly it isn't, then it violates the previous SDK agreement clause.
Opera Mini does process compress data sent by Opera server. If the engine that process the compressed data is not native a Apple's API, which clearly it isn't, then it violates the previous SDK agreement clause.
You're not suggesting it's not possible to draw pictures using the standard APIs, are you? Because that pretty much how it comes across. To my best guess, this thing will be an app which receives a stream of data and represents it on a screen. Much like, say, an online game.
I am not buying it, his other argument about only webkit being allowed is understandable. But to say code is executed remotely, well, no, that happens in all servers.
Actually, the point wasn't that code was executed remotely, but that it was executed and/or interpreted without going through Apple's APIs -- in this case WebKit. Thus, a browser or web view using WebKit is fine, but one that doesn't isn't. Feel free to disagree, but do argue against what I actually said.
Whoops. The Opera Mini wagon just lost a wheel.
How come? It has not prevented its adoptions so far. Opera Mini gets about 4-5 million new active users each month. Opera has an excellent privacy track record, as a matter of fact.
You're not suggesting it's not possible to draw pictures using the standard APIs, are you? Because that pretty much how it comes across. To my best guess, this thing will be an app which receives a stream of data and represents it on a screen. Much like, say, an online game.
An online game are processed using Apple's Documented APIs and built-in interpreters to be displayed on screen.
I hope they allow it, but force them to call it something else besides a web browser.
It is a web browser.
A technology with a huge downside to the consumer that Opera never talks about much and that the average consumer has no way of knowing about unless they are a techie.
Never talks about? Opera always talks about how they are compressing data before sending it to the phone.
The more I think about it, Opera will probably refuse the idea that they have to put scary warnings on it and make it obvious to the end user how insecure the thing is
Opera Mini isn't insecure, and Opera Software has an excellent security and privacy track record.
And they are always bragging about how their server-side compression makes it insanely fast. You are claiming that they are trying to hide it, but that's just a lie.
There are more reasons to dis-allow this based on consumer "expectation" and safety
Again, this is nonsense.
The problem is that a browser engine provides a javascript runtime, and runtime environments are specifically banned by the iPhone developer agreement.
No, JavaScript is handled on the server.
Duplicates functions of the iPhone. Rejected.
As did Spotify. Rejected?
No pinch to zoom.
It's even easier: Just tap where you want to zoom.
No security.
Wrong. The connection to the proxy server is secure.
Who would use this??
Anyone not on a perfect connection.
Anyone who doesn't want outrageous roaming charges.
Anyone who doesn't have an unlimited data plan.
No pinch-to-zoom, and there *will* be page-rendering issues.
I use it on my E72, and have used it on my other Nokia devices. Outside of the pinch and zoom it works fine. I do not think, no I am sure you do not know what you are talking about. It uses SVG to format and render pages.
It is technically a web browser but one that operates in a significantly different manner from every other web browser and operates through proxy servers that the end user is essentially unaware of, and thus is a completely different animal. ....
fixed that for you.
Also, please look up "gainsaying," and find out how little it has to do with logic or argument.
I do not think, no I am sure you do not know what you are talking about. It uses SVG to format and render pages.
Perhaps, but they still have to render the pages to SVG on the proxies, so the possibility of rendering problems isn't obviated by that.
Opera Mini does process compress data sent by Opera server. If the engine that process the compressed data is not native a Apple's API, which clearly it isn't, then it violates the previous SDK agreement clause.
Apple API does not do your work for you as a programmer. You are still expected to write the code, using the provided API when necessary. Opera could written their own decompression algorithm. That in and of itself is not a violation of the SDK, at least not the clause quoted.
How does a decompression engine violate this:
"An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s)."?
Any decompression will be built into the app, so it would't be launching (or installing) additional executable code. Decompressing a data stream is not the same as interpreting or executing additional code. If Opera's implementation does rely on interpreted code or launching additional executable code, outside of their app (not on a server), then yes, they are in violation. I just don't see how you can say decompressing data is in violation, simply by being decompression.
blah blah blah ...
I think this is a slam-dunk rejection for violating the developer agreement and for undermining the iPhone user experience and security. Apple should just put this on the fast track, reject it, and be done with it, preferably by the end of the day. It's not like more than a handful of people care about Opera anyway, and it's not like it offers anything useful without also bringing huge downsides with it. ...
Anonymouse wins the thread! Yay!
Seriously, "Tulkas"??? you filled pages and pages of writing and I've read it all and you just don't have any argument against what anonymouse is saying. Nothing. Nada.
Anonymouse like all of us, could turn out to be wrong, but nothing you have said indicates that in any way. You are just being bitchy and harping about perceived details in conversations that didn't actually even happen the way you thought they did.
I don't claim to know for sure, but I think its safe to assume anything that leaves from, or arrives at your modem is pretty efficiently compressed already. And JPEGS etc. are already about as compressed as they can be without further loss. I would assume a compressed image of a web page would be more verbose than a compressed file of the HTML that describes that page. So I'm wondering where the gain is.
Is it just in making a choppier versions of web pages?
No, really you can gain a ton of speed by simply removing all the white space and line returns. For example all the big sites like Google and even the JS libraries are really compressed. It makes a huge difference. The code is no longer human readable but that is managed by maintaining a working version.
In the case of Opera their servers are compressing the regular html code. Average website code is not compressed at all. If you right click and view source that is what the browser sees. it doesn't uncompress any text. Opera is different with their iPhone browser, it will uncompress their specially encoded text as well as the photos.
Many web developers don't take the time to optimally compress or size their images either. Everything gets saved at quality 8 and then they often scale it in Dreamweaver which is totally slacker way of doing things. If a smart server can overcome these problems it makes sense to do it.
However the lack of https encryption in Opera mini is a deal breaker.
THIS PRODUCT IS NOT GOOD FOR SECURE COMMUNICATION!
Sure it is.
So what's the point of this software?
Even if you don't want to use it for banking and stuff like that, it can still be used for reading news, etc.
I'm not seeing much of a reason to give up your privacy and have each and every web site you visit processed by Opera Software.
Opera Software has an excellent privacy track record, so that really isn't a problem.
They might also have something going for it in compression... but many web sites do that on their own now don't they?
No. Opera Mini compresses data up to 90%.
So what is the point???
It's for anyone not on a perfect connection.
Anyone who doesn't want outrageous roaming charges.
Anyone who doesn't have an unlimited data plan.