Yeah Safari has it's own "fast javascript engine." It's treated me well, though I could see Google's money making v8 the king of the Hill for both browsers in the long run. I grok the technical implications of what you gentlemen are saying. They're real. I wanted to diverge a bit though. I don't think the technical issues come primarily from a real security perspective: I believe that the biggest barriers to many of the things we want to do (in particular, compile code on the device) stem from Apple's *desire for control of the distribution channel*. John, I've been wondering: Is this the main reason I cannot purchase your Squeak VM on the App Store? I dig my wiki server, but I'd really really like to be able to Squeak on my phone without voiding the warranty. On Thu, Oct 22, 2009 at 3:11 PM, Eliot Miranda <[hidden email]> wrote: > > > > On Thu, Oct 22, 2009 at 2:08 PM, John M McIntosh <[hidden email]> wrote: >> >> >> On 2009-10-22, at 1:41 PM, Eliot Miranda wrote: >> >>> Its OK if you're Apple, right? JavaScript is V8 (a JIT) on the iPhone isn't it? > > At least on Safari it is "Nitro". So I guess Mobile Safari doesn't contain V8 either. > >>> >>> And if Java is on the iPhone its probably a JIT too. >> >> Er yes, well it's your operating system, your hardware, your legal documents. One can do what one wants, as long as one can >> keep the other guy out of your playpen. So who does hand executable pages to V8? Good question... >> >> Java is NOT on the iPhone. Neither is Flash. *cough* well interpreted flash, Adobe has some static compiled >> version they make or something now. Grind Flash thru some process, makes iphone app. >> >> -- >> =========================================================================== >> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> > > > -- Ron |
2009/10/23 Ronald Spengler <[hidden email]>: > > Yeah Safari has it's own "fast javascript engine." It's treated me > well, though I could see Google's money making v8 the king of the Hill > for both browsers in the long run. > > I grok the technical implications of what you gentlemen are saying. > They're real. I wanted to diverge a bit though. > > I don't think the technical issues come primarily from a real security > perspective: I believe that the biggest barriers to many of the things > we want to do (in particular, compile code on the device) stem from > Apple's *desire for control of the distribution channel*. > Store since then :) And allowing or disallowing native execution for memory page has nothing to do with real security, this is just a myth. > John, I've been wondering: Is this the main reason I cannot purchase > your Squeak VM on the App Store? I dig my wiki server, but I'd really > really like to be able to Squeak on my phone without voiding the > warranty. > -- Best regards, Igor Stasenko AKA sig. |
Even without JIT, we're not allowed in. There's a rule against interpreting code too; clearly this is a very flexible rule, as I can't think of a game company that uses any variant of C for in-game scripting, not to mention that we have apps running Squeak. My guess is they'll let you do it as long as you don't let end users do it. Hence, not a security concern. I am uncertain whether it's presently okay or not okay (it's been both okay and not okay at different times) to reproduce any part of the SDK agreement, so I'll just point at section 3.3.2. On Thu, Oct 22, 2009 at 8:42 PM, Igor Stasenko <[hidden email]> wrote: > > 2009/10/23 Ronald Spengler <[hidden email]>: >> >> Yeah Safari has it's own "fast javascript engine." It's treated me >> well, though I could see Google's money making v8 the king of the Hill >> for both browsers in the long run. >> >> I grok the technical implications of what you gentlemen are saying. >> They're real. I wanted to diverge a bit though. >> >> I don't think the technical issues come primarily from a real security >> perspective: I believe that the biggest barriers to many of the things >> we want to do (in particular, compile code on the device) stem from >> Apple's *desire for control of the distribution channel*. >> > +1 once one can compile own code on their devices, he won't need App > Store since then :) > And allowing or disallowing native execution for memory page has > nothing to do with real security, > this is just a myth. > >> John, I've been wondering: Is this the main reason I cannot purchase >> your Squeak VM on the App Store? I dig my wiki server, but I'd really >> really like to be able to Squeak on my phone without voiding the >> warranty. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Ron |
On Oct 22, 2009, at 8:47 PM, Ronald Spengler wrote: > I am uncertain whether it's presently okay or not okay (it's been both > okay and not okay at different times) to reproduce any part of the SDK > agreement, so I'll just point at section 3.3.2. 3.3.2 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 and used in an Application except for code that is interpreted and run by Apple's Published APIs and built- in interpreter(s). |
On 23.10.2009, at 05:58, Ian Piumarta wrote: > On Oct 22, 2009, at 8:47 PM, Ronald Spengler wrote: > >> I am uncertain whether it's presently okay or not okay (it's been >> both >> okay and not okay at different times) to reproduce any part of the >> SDK >> agreement, so I'll just point at section 3.3.2. > > 3.3.2 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 and used in > an Application except for code that is interpreted and run by > Apple's Published APIs and built- in interpreter(s). Yep - emphasis on *downloaded* code. As long as all the interpreted code ships with the app and there is no way to download additional code except through the App Store, Apple is fine. So you can make Squeak apps available through Apple, that's just what John did. - Bert - |
Hi all! Some interesting points: On Android you can install an app just by clicking on it in the web browser and bam, it will install. AND it can contain native libraries in C or whatever BUT AFAICT it needs to "be" a Dalvik Java app around it. For example, someone just published Quake wrapped in a very thin Java/Dalvik layer around Quake as a C lib working using OpenGL ES. THUS... Android is MUCH more fun for Squeak. There is no central bottleneck like the App store. Secondly, there are TONS of Android phones coming out the next few months. The one that most waits for is "The Droid" from Motorola (Motorola is going "all in" on Android): http://droiddoes.com They take iPhone head on :) Note also that the Mono folks are all over Android now, the mono JIT seems to run fine, see below. Finally, some links: http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html Note that Dan Bernstein (designer of Dalvik?) comments it below. regards, Göran |
2009/10/23 Göran Krampe <[hidden email]>
Goran, thanks for this link. In particular this is a neat idea:
I believe you didn't understand Dan's presentation after all. Note that Dan Bernstein (designer of Dalvik?) comments it below. |
In reply to this post by Casey Ransberger
ok just to help Ron here, developers who sign the contract with apple can not talk about the contents of the contact. This is the current view which was confirmed to us by a call from apple legal three weeks back to have us remove two words from one of our iTunes store app decriptions On 10/22/09, Ronald Spengler <[hidden email]> > > I am uncertain whether it's presently okay or not okay (it's been both > okay and not okay at different times) to reproduce any part of the SDK > agreement, so I'll just point at section 3.3. >> -- =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Free forum by Nabble | Edit this page |