or Connect
AppleInsider › Forums › Mobile › iPhone › Opera submits iPhone browser to Apple for App Store review
New Posts  All Forums:Forum Nav:

Opera submits iPhone browser to Apple for App Store review - Page 2

post #41 of 123
Quote:
Originally Posted by NasserAE View Post

Opera knows this app will be rejected because the app violates the iPhone SDK agreement. Everyone knew that since the first public release of the app store.

"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)."

Could you explain how you see Opera as violating the quoted restriction?

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #42 of 123
Quote:
Originally Posted by mr_cazorp View Post

From the Opera mini browser FAQ

Is there any end-to-end security between my handset and for example paypal.com or my bank?

No. If you need full end-to-end encryption, you should use a full Web browser such as Opera Mobile.

I'll pass.

"me too."

opera for the iphone is reliant on the transcoder/proxy that sits between the iphone and the target website. a secure request (https) is decrypted at the proxy/transcoder and then re-encrypted before sending the request on to the target website. likewise on the return trip. used to be referred to as the wap-gap. anyone with access to that proxy/transcoder has access to the specifics of the request.

so no thanks, to any proxy/transcoder based browser.

"just because i'm paranoid doesn't mean they're not out to get me."
post #43 of 123
Quote:
Originally Posted by NasserAE View Post

Opera knows this app will be rejected because the app violates the iPhone SDK agreement. Everyone knew that since the first public release of the app store.

"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)."

Quote:
Originally Posted by Tulkas View Post

Could you explain how you see Opera as violating the quoted restriction?

It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
post #44 of 123
Quote:
Originally Posted by aaarrrgggh View Post

Application level compression is most effective, especially given latency and processing limitations of different software and hardware.

What I don't understand is why mobile safari doesn't support gzip compression built into most web servers.

Server-side compression is something I still miss from my blackberry, although better rendering makes up for it generally.

I'm unclear what is being compressed. From the article it seems they are rendering the page elsewhere and sending it as a single page image (presumably adding buttons at links.) I'm surprised this makes it smaller or faster than the HTML itself. What am I missing?

BTW, did anyone else notice in the demo video, the progress bars all seem to indicate that Opera is still rendering/downloading when they press the next link. What does this mean? Are they "cheating" in the demo?
post #45 of 123
Quote:
Originally Posted by neondiet View Post

Yeah, rejection of Opera for no good reason other than to restrict competition will expose Apple to a complaint for breach of EU Competition Law.

I don't quite see how that would apply, seeing as how the iPhone "App Store only" model for native apps is allowed, and tons of phones don't even allow another browser to be used or installed (even in the EU).

Technically though Opera Mini is a scary beast, as already said by a ton of people. The traffic is still encrypted as I understand it, but instead of it being You > Bank, it's You > Opera > Bank.

Basically, if they were so inclined Opera would have full access to your bank account etc. Balls to that!
post #46 of 123
Quote:
Originally Posted by anonymouse View Post

It seems pretty obvious to me. It launches other executable code on Opera's proxy's, thus falling foul of at least the "otherwise" clause. It uses interpreted code not run by Apple's Documented APIs and built-in interpreter(s) by running JavaScript on those proxies. The quoted restriction doesn't limit itself to "other executable code" or interpreters located on the iPhone. Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).

Uh Oh, the entire internet just got banned by this explanation....

Sometimes, when 'things' are invoked through a web page from a server, on a network, it results in code being executed....sort of the basis for network based computing. Any browser that connects to the Apple site results in WebObjects code being called and executed. Any web page loads results in servers executing code.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #47 of 123
Quote:
Originally Posted by Tulkas View Post

Uh Oh, the entire internet just got banned by this explanation....

Sometimes, when 'things' are invoked through a web page from a server, on a network, it results in code being executed....sort of the basis for network based computing. Any browser that connects to the Apple site results in WebObjects code being called and executed. Any web page loads results in servers executing code.

Only when you conveniently ignore that

Quote:
Originally Posted by anonymouse View Post

... Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).
post #48 of 123
Quote:
Originally Posted by DESuserIGN View Post

I'm unclear what is being compressed.

The html code is text. They use text compression like LZW maybe.

Basic concept is this:

Common character strings are reduced to a numeral.

For example the html text class=" or style=" might be sent as numeral keycodes which it keeps in a dictionary of sorts this can save about 85%

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #49 of 123
Quote:
Originally Posted by anonymouse View Post

Only when you conveniently ignore that

... Other browsers or apps with web views are fine because they go through Apple's Documented APIs and built-in interpreter(s).

...resulting in code being run on remote servers. So, in other words, it completely abides by the SDK restriction, as much as any other browser or app that using a network connection.
It isn't a matter of ignoring that statement of yours, it is recognizing how totally irrelevant it is.

-All browsers result in code being executed remotely when browsing to web pages.
-Opera and other iPhone browsers abide by the rules set out in the SDK for app development.
-claiming that Opera then violates the SDK because it results in code being executed remotely, as the other browsers also do, is then just a dumb argument.

"opera violates the SDK" "Why?" "because they result in remote code being executed" "But so do other browsers and apps" "The other apps followed the SDK, so opera didn't" "waht?" "Opera didn't because Opera didn't, because others did, so Opera didn't"
Nice logic.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #50 of 123
Quote:
Originally Posted by Tulkas View Post

...resulting in code being run on remote servers. So, in other words, it completely abides by the SDK restriction, as much as any other browser or app that using a network connection.
It isn't a matter of ignoring that statement of yours, it is recognizing how totally irrelevant it is.

-All browsers result in code being executed remotely when browsing to web pages.
-Opera and other iPhone browsers abide by the rules set out in the SDK for app development.
-claiming that Opera then violates the SDK because it results in code being executed remotely, as the other browsers also do, is then just a dumb argument.

"opera violates the SDK" "Why?" "because they result in remote code being executed" "But so do other browsers and apps" "The other apps followed the SDK, so opera didn't" "waht?" "Opera didn't because Opera didn't, because others did, so Opera didn't"
Nice logic.

It's really quite simple, despite the twisted mess of "reasoning" above. Apps that use WebKit for web access are fine, those that don't aren't. Apps that have been approved do, Opera doesn't.

Of course, there are, as has been pointed out, a number of other perfectly good reasons for Apple to reject Opera, some of which are along the same lines of why Google Voice was rightly rejected.
post #51 of 123
Quote:
Originally Posted by mstone View Post

The html code is text. They use text compression like LZW maybe.

Basic concept is this:

Common character strings are reduced to a numeral.

For example the html text class=" or style=" might be sent as numeral keycodes which it keeps in a dictionary of sorts this can save about 85%

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?
post #52 of 123
Quote:
Originally Posted by anonymouse View Post

It's really quite simple, despite the twisted mess of "reasoning" above. Apps that use WebKit for web access are fine, those that don't aren't. Apps that have been approved do, Opera doesn't.

Of course, there are, as has been pointed out, a number of other perfectly good reasons for Apple to reject Opera, some of which are along the same lines of why Google Voice was rightly rejected.

Yes, it is a twisted mess of reasoning. Irrational arguments tend to be.

So, now you have changed your argument to their choice of browser engine (when one argument fails, change arguments, I suppose...) Might be a good argument, but it doesn't relate to the SDK quote in question. If you could quote the SDK clause that specifically forbids the use of alternative engines, you might have a leg to stand on. Of course, I expect you won't be able to find such a clause.

The only argument relating to a violation of the SDK, might be, as you say, the same used for GV. Apple might claim it duplicates existing functionality. Of course, that would be strange, as it was in the GV case, since if it can be considered duplication then there are certainly other examples in the same categories which are also duplications and allowed. So, again you are right, banning Opera might make as little sense as banning the GV app.

In the end, it is silly and a waste of time to try to assume reasons for some apps being banned. Usually, those that need to argue that Apple is right, regardless of circumstance, end up being proven wrong or inconsistent when they try to use 'facts' to justify their arguments. They always end up going to one and only one argument, that being "It is Apple's iPhone, SDK and AppStore and so they can do as they please". Not a very compelling argument as to the why, but they seem to confuse this with the how.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #53 of 123
Just got caught up with the comments. Anonymouse's comment about code being executed remotely on an Opera server would still violate the SDK rules is an interesting take. I'm completely buying it, but I also wouldn't put it past Apple as a reason.
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
post #54 of 123
Quote:
Originally Posted by Tulkas View Post

Yes, it is a twisted mess of reasoning. Irrational arguments tend to be.

So, now you have changed your argument [...]

In the end, it is silly and a waste of time to try to assume reasons for some apps being banned. [...]

No, I haven't changed my argument at all, but I really can't be bothered with trying to parse your confused counterargument to refute it point by point. I've given my reasons, and expressed my expectations that Opera Mini will not be approved.

In regard to why apps are not accepted, I would note, that in terms of what's come to light in the interim, I was right about the reasons GV was not approved. That was also pretty obvious to anyone with an open mind and any sense of what's important to Apple.

Apple rightly won't approve Opera, and there won't be any even moderately significant fallout from not doing so.
post #55 of 123
Quote:
Originally Posted by anonymouse View Post

No, I haven't changed my argument at all, but I really can't be bothered with trying to parse your confused counterargument to refute it point by point. I've given my reasons, and expressed my expectations that Opera Mini will not be approved.

of course you have. You perhaps just aren't able to see that.

Quote:
Originally Posted by anonymouse View Post

In regard to why apps are not accepted, I would note, that in terms of what's come to light in the interim, I was right about the reasons GV was not approved. That was also pretty obvious to anyone with an open mind and any sense of what's important to Apple.

No, you were adamant that it was a concern for privacy because of the evil info collecting of Google. Apple even agreed with you on this in their FCC response, so a point for you (but, then they also said it replaced core functions of the OS, so maybe the FCC response was bollocks). With "what's come to light in the interim" it is pretty clear the only reason it was rejected/not approved was because of the perceived insult to Apple/Jobs of Android. No privacy concerns at all.

Quote:
Originally Posted by anonymouse View Post

Apple rightly won't approve Opera, and there won't be any even moderately significant fallout from not doing so.

You are right, likely they won't approve it and there will be little fallout. It isn't the end of the world. But, certainly, pre-rendering the pages on remote servers, doesn't violate the SDK clause regarding API usage, code execution or code interpreters. That much is obvious...or should be to most.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #56 of 123
I'm seriously laughing my ass off at all the fanboys on this on.

You want to wiki something? Opera mini.

You want to pay bills? Safari

It's as simple as that.
post #57 of 123
Quote:
Originally Posted by Tulkas View Post

of course you have. You perhaps just aren't able to see that.


No, you were adamant that it was a concern for privacy because of the evil info collecting of Google. Apple even agreed with you on this in their FCC response, so a point for you (but, then they also said it replaced core functions of the OS, so maybe the FCC response was bollocks). With "what's come to light in the interim" it is pretty clear the only reason it was rejected/not approved was because of the perceived insult to Apple/Jobs of Android. No privacy concerns at all.

I suggest you go back and read my posts in this thread, and in other threads regarding GV, and you'll find you are incorrect in all your above assertions.
post #58 of 123
Quote:
Originally Posted by anonymouse View Post

I suggest you go back and read my posts in this thread, and in other threads regarding GV, and you'll find you are incorrect in all your above assertions.

Oh, I think we all recall the tinfoil hat claims made in the GV threads.

As for your 'arguments in this thread, they are little more than obviously wrong statements, confused ramblings and 'evolving' arguments.

Only one point you have made has any merit as far as SDK clauses that might be used to block that app. Duplication. Which, as we have seen, is simply a vague, lazy, catch all used when there is no valid reason.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #59 of 123
Quote:
Originally Posted by Tulkas View Post

Oh, I think we all recall the tinfoil hat claims made in the GV threads.

As for your 'arguments in this thread, they are little more than obviously wrong statements, confused ramblings and 'evolving' arguments. [...]

Actually, I think my first post in this thread, #39 I believe, pretty much lays out my position, and I don't see how any of my subsequent posts deviate from that position in any significant way.

As for "tinfoil hat claims", I guess you apply that to anyone who asserts Google is a potentially, if not already actually, problematic company? I guess it's a sort of argument, but not much of one.
post #60 of 123
Quote:
Originally Posted by solipsism View Post

Just got caught up with the comments. Anonymouse's comment about code being executed remotely on an Opera server would still violate the SDK rules is an interesting take. I'm completely buying it, but I also wouldn't put it past Apple as a reason.

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.
post #61 of 123
Quote:
Originally Posted by anonymouse View Post

Actually, I think my first post in this thread, #39 I believe, pretty much lays out my position, and I don't see how any of my subsequent posts deviate from that position in any significant way.

Ok, let's look at post #39 (and ignore for the moment that your GV was not about the what potential Google has for evil but how evil the are).

here we go.


Quote:
Originally Posted by anonymouse View Post

I'd be completely and utterly shocked if it were approved because a) it is in fact a browser, regardless of how that functionality is implemented, that violates the terms of the developer agreement, b) it is, as you point out, "dangerous" because it, "doesn't provide any of the standard protections people expect to be there," and c) Opera are clearly baiting Apple, in a rather childish manner, in fact.

a) Bullshit. Please provide the SDK clause the expressly forbids all browsers. We'll wait. (of course, you have since changed it from a laughable claim that it being a browser is enough for it being in violation to the fact that it doesn't use webkit-changing one's argument is easier than just admitting you were wrong, I guess.)
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 (you know, the ones you claim are a violation by virtue of existing, yet exist). Not like Opera makes a secret of this. Maybe some people really would be confused when Opera says No. If you need full end-to-end encryption, you should use a full Web browser.
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' instead of 'submitting an app'. Is this really an argument? They submitted it (or 'baited Apple') so it should be rejected because they submitted it? really? This is your 3rd of 3 point? really? The reason for rejecting it is because it was submitted?
Really? Logic isn't everyone forte, but f*ck, basic reasoning should be mandatory for a HS diploma.

Quote:
Originally Posted by anonymouse View Post

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.

Certainly an opinion. Not one particularly based in facts, but an opinion nonetheless...I guess everyone really does have one of those too.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #62 of 123
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.
post #63 of 123
Guaranteed to be rejected.

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.
post #64 of 123
Quote:
Originally Posted by Tulkas View Post

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.
post #65 of 123
Quote:
Originally Posted by anonymouse View Post

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.
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.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #66 of 123
Quote:
Originally Posted by Tulkas View Post

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.
post #67 of 123
Quote:
Originally Posted by NasserAE View Post

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.
post #68 of 123
Quote:
Originally Posted by myapplelove View Post

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.
post #69 of 123
Mozilla is finding the same problem with WinPh7...
http://arstechnica.com/microsoft/new...-on-winmob.ars
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
post #70 of 123
Quote:
Originally Posted by Quadra 610 View Post

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.
post #71 of 123
Quote:
Originally Posted by djsherly View Post

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.
post #72 of 123
Quote:
Originally Posted by Gazoobee View Post

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

Again, this is nonsense.
post #73 of 123
Quote:
Originally Posted by senjaz View Post

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.

Quote:
Originally Posted by Eriamjh View Post

Duplicates functions of the iPhone. Rejected.

As did Spotify. Rejected?
post #74 of 123
Quote:
Originally Posted by Phizz View Post

No pinch to zoom.

It's even easier: Just tap where you want to zoom.

Quote:
No security.

Wrong. The connection to the proxy server is secure.

Quote:
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.
post #75 of 123
Quote:
Originally Posted by Quadra 610 View Post

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.
post #76 of 123
Quote:
Originally Posted by insike View Post

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.
post #77 of 123
Quote:
Originally Posted by sapporobabyrtrns View Post

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.
post #78 of 123
Quote:
Originally Posted by NasserAE View Post

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.

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply

"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. 

...sometimes it's both
Reply
post #79 of 123
Quote:
Originally Posted by Tulkas View Post

blah blah blah ...

Quote:
Originally Posted by anonymouse

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.
post #80 of 123
Quote:
Originally Posted by DESuserIGN View Post

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.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
AppleInsider › Forums › Mobile › iPhone › Opera submits iPhone browser to Apple for App Store review