With the new hassle of code sharing, I wondered if there was any major problems with condensing a project to a single file for the purpose of sharing. I realise that the editor goes a bit slow on a large file, but does the interpreter?
I’m particularly thinking of sharing projects with people who aren’t going to be really interested in editing them but just in running them, though ease of sharing with other hackers here is also a consideration.
The interpreter should be the same. One of the last-resort code sharing solutions I have in mind involves a single large file that can be “copied” from your project, then pasted somewhere else. And a mechanism to paste a large chunk of text and have Codea automatically split it into files.
Andrew, you and I have both made what boil down to the largest (in terms of lines of code) projects around - now that spinnies are fixed, I haven’t had issues with several thousand lines.
I’m half-tempted to push the limit and see what happens. Large image files, anyone? 
Hmm. Do we have a way, yet, to make an image other than single pixels? No. THAT needs fixin.
Do we have any methods for moving code and data in 1.2.7? Bortels, your webtool handles only code right?
Is a zip/tar/whatever file that people extract into the ipad with iexplorer the best solution at this point?
I think iExplorer is probably the best solution. I’ve called Apple asking for further discussion about this - I hope they get back to me.
Here’s the exact wording of the terms relating to the removal of this feature:
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
I’m trying to think of a project sharing mechanism that does not violate this term. I believe Codea’s project sharing doesn’t violate the spirit of the term (create features or functionality inconsistent with the intended and advertised purpose).
Simon, good luck on your talks. It’s not the letter of the rule that they go by, afterall browsers can download executable code. Codea does’t download any code at all. (Instead it knows how to open code that users download from a browser.).
I think you got the right approach of presenting alternatives and saying: “is this ok? How about this?” etc because it’s the type of thing that they’ll know when they see it.
I would remind them, in the appeals, that interpreters were also prohibited at one point, and are now allowed.
I’ll be blunt - .codea code sharing clearly violates this clause. Moreover, allowing cut and paste does so as well. This doesn’t mean they should be prevented - it means they’re an edge case this clause didn’t anticipate, and the rules should be updated to reflect the reality at hand. Specifically - this clause (and “no interpreters” before it) were meant to prevent Flash from “coming in the back door” on the iOS platform, and they’ve succeeded. Good for them, but this particular prohibition has outlived it’s usefulness - rather than protecting the platform, in the long term it’s going to teach people that the right place to create code, and learn, and play… is elsewhere.
They already list webkit as an exception - it’s simple enough to make others, and have a seperate vetting process where they confirm the environment is sufficiently sandboxed to be safe. (Sadly - I suspect sockets will still be out in such an environment…)
I’ve always been a little disappointed Apple didn’t have the cojones to just say “We don’t like Flash, we think it’s a pig and unstable, and makes systems it’s on unstable, and here’s our evidence. Thus - we don’t approve it for the App store. Next topic!” - rather than rules-lawyer it to try to pretend that the banning of flash was in some way an accident of design. I’m also disappointed that they won’t take a chance and see if it actually causes problems before they deny things - people that expect the worst all of the time often times get what they expect.
I believe the rule about interpreted code has always been there and had nothing to do with Flash.
They have always said that they disliked flash and would not include it as a plugin.
Apple relaxed the rule when it became apparent that too many already-approved apps relied on breaking it (Unity games, Flash-to-native apps, and so on).
Apple has a history of tweaking the rules to block competition from entering into App Store Apps (not just for apps - they also ban third party ads not using their own stuff, but only from big ad networks like google, or they did - I don’t know if it’s still the case, I suspect so). Like I said before - it’s their store, they should simply refuse the apps, but presumably that might get them sued, so they play jiggery-pokery with the rules.
Which plays to our favor - Apple isn’t trying to block Codea and it’s users - we’re just collateral damage in it’s wars with the big boys. And Apple has taken steps, in the past, to reword things so that we can do what we want to do (which isn’t causing Apple harm) while still preventing the activity they don’t like, Unity being a really good example (mainly, other large concerns becoming arbiters of what Apple can or cannot do - they REALLY didn’t like Adobe yanking their chain when it came to porting “must have” apps like Photoshop, and I don’t blame them). Apple resolved - correctly - to never be in that situation again.
Also worth pointing out, from their own review documentation:
“This is a living document, and new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this.”
http://daringfireball.net/2010/09/app_store_guidelines
I actually think that line is meant as a threat, of sorts - just because we approved apps that did this in the past doesn’t mean we’ll keep doing it. But that door works both ways.
@Bortels the Apple Insider article says that Apple relaxed restrictions on downloadable code, which allowed Flash-based games on the App Store (such as Machinarium). They’ve always been upfront about blocking Flash as a browser plugin.
I think the restriction really was to force developers into the Xcode environment. But that environment is not always the best for game development, so it was relaxed. My thought is that Apple didn’t want people using third-party UI toolkits to make apps that might not be consistent with the iOS look-and-feel.
Mmmmm… ok. It’s Air, not flash, but so far as I can tell Air is a flash compiler, so “meh”. If I write a program to translate lua to, say, javascript, and run it that way - is it Lua? Yes! and No! And it appears Air is an example of that. It’s all machine code deep down anyway.
But… presumably not downloadable, yes? I mean - that’s the whole thing we’re arguing about, Codea downloading code. You buy Machinarium, you get a full reviewed app - it doesn’t download more code, right? (if it downloads more interpreted code - there’s your example)
The phrase “…that environment is not always the best for game development” is the understatement of the year!
My read on it was that Apple had got yanked around in the past with Adobe not updating it’s products, including Flash, in a timely manner with respect to the equivalent windows versions. Jobs being a control freak (which is not necessarily a bad thing), he didn’t want his platform at the mercy of the whims of a third party, which is what it would be if most of the stuff used flash, which is frankly what would have happened had he allowed it from the beginning. Plus the whole crashy crashy thing, which is true, and a good reason, but not the real reason he banned it.
But he’s dead, and nobody is ever going to be able to definitvely pin down motives at this point, so true motives for who did what why are going to remain murky at best.
I'm trying to think of a project sharing mechanism that does not violate this term.
Before I suggest or resuggest an idea I need to frame the discussion.
Software can be deemed “bad” if it violates the business interests of the platform or is just a plain virus. In this vein stuff that isn’t allowed is just the same as a virus.
In software or biology a virus needs a vector (not vec2 or vec3, goggle virus vector). All preventions of a virus (and to a wider extent security issues) have to do with controlling vectors.
A key component in any vector is speed. Slowing down vector speed is nearly as good as vector elimination. In fact in just about all cases vectors can never be eliminated only slowed.
Linking this back to business interests, a “real” app store app has a quick vector by design. This is entirely intended as it is the core business model.
In summary anything that competes with “real” apps is considered harmful and anything that is harmful for pratical terms only needs slowed and not stopped.
So the idea… Ok more background
I can download executable code in fact an entire operating system into an app. Now, this app is only an unarchiver so I cannot execute it. I can also cut/paste into the notes app. If app cannot allow downloadable code then all the lua example I have in Apple’s notes app make notes banned and notes should be removed from all current and future versions of the operating system.
On more thing before wrapping up.
The problem with the .codea was not the export, it was the input. The speed of clicking a web page, opening in app, and execution rivaled the app store. Forget about malicious code, it’s a simple business model issue.
The solution?
Allow Codea to open .codea files directly as before BUT to an inert state where the content either have to be cut/paste or pulled in (not moved to) a project one a time (code and data files).
Apple was always upfront about not wanting Flash on its products - for the reasons you stated.
My point is that the rules on downloadable code aren’t some sneaky way to disallow flash, they were upfront about that. The rules on downloadable code were more about ensuring a consistent look-and-feel for native apps. Encouraging adoption of their development environment.
Codea doesn’t download code by the way. Unfortunately their wording says download or install executable code. And Codea was able to install code.
“A key component in any vector is speed. Slowing down vector speed is nearly as good as vector elimination.” +1 Insightful.
I did some simulations a while back, comparing spread rate on a network where 10% of the systems were susceptable, versus 90%. Stunning differences.
But - not the issue apple cares about, methinks - they aren’t concerned about virus, so much as trojan.
Here’s a scary example: I embed, in my giant (and popular) Codea app, a well obfuscated routine (it’s in the middle of a compressed blob of data used for a font, say). That routine is going to trigger at some point in the future, and on any time past my trigger day, my app displays an advertisement for, uh, Ford Trucks (Built Ford Tough!). Apple is pretending that their review process would have caught this and prevented it - the app is a trojan for it’s actual purpose, and violates their policies about that right and left.
Not scary enough? Ok - the app shows a picture (photoshopped) of your-favorite-political-candidate-here with a goat and a midget.
Sorry - it’s hard to think of a good payload when you can’t talk to the real world. I hate to even say it, but if we had sockets, you could do a pretty effective DDoS - you don’t need a lot of horsepower for that, you need a ton of clients. Yes, scary. Not very likely - a popular app would be vetted by many eyes, this being forced open source, but still.
mmm - that may be another angle. @Simeon, remind them this is open source code we’re sharing - the chance of someone doing shenanigans without it being immediately apparent and dealt with are minimal.
Point being - they probably are not concerned about the virus aspect so much as the trojan, and the trojan payload need not be something you or I consider bad - it could be as simple as advertising that Apple disapproves of. So far as Apple is concerned, it’s not you or I doing it - it’s TLL and Codea.
I have never heard the term DDoS, understand what it is, nor would be or have been willing to participate in this thing that I know nothing about. (these are not the droids you are looking for)
I think their concern is preemption of the app store, apple is nothing if not control freaks but that is part of why their products work the way they do.
Ok - another angle. Get ready for world-class rules lawyering here:
“download or install executable code”.
So - download you don’t do. Something else does, sends it to you. More importantly for this, it’s triggered by the user, not by Codea. You’re a push recipient - you don’t pull. You’ve said so yourself - just re-establishing that fact. No Download.
“install executable code”. Ok, I may be pedantic here, but so are the rules - is lua source “executable code”? We can use Codea to execute it, certainly - but what’s being downloaded/installed is text - no opcodes, no binary - it’s words. Mostly in english, with punctuation. It’s source code, surely - but there’s a differentiation between “source code” and “executable code” - they are not the same, that’s what a compiler is for. You are arguably not installing executable code - you’re installing source, that you may later compile and run (by pushing the run button in the corner).
That may seem pathetic - and I’d say “dude, that’s a stretch” - but there’s an important point here. Codea doesn’t download code, it’s not executable (ie. Object) code - it’s presented by default to the end-user for inspection, and that end user has to actively choose to compile and execute the code. If the code was opaque, this would be “executable code” - but it’s not, it’s source.
or, as has been suggested, if they’re prohibiting the ability to install source code - kill notepad. And they explicitly allow interpreters to execute code, so long as they don’t download it - which Codea does not.
DISCLAIMER: The above is a house of cards. I’m ashamed to even present it. If I was in debate (I loved debate in college), I’d be unable to respond because I’d be laughing so hard. Take it as comedy if you want, but maybe there’s something there to use.
I’m going to try that argument anyway. And then maybe start discussion on similar functionality under a different name (copy and paste).
opaque got me thinking
http://blog.grumpycoder.net/index.php/post/2009/09/30/Lua-tricks-Carbonite-obfuscation
Bortels, your lawyering is why i say this is not about the rules as written down. It’s about what they’re comfortable with to make sure they control ipad experience. All these arguments are firepower for TLL but at the end of the day, it’s about what apple wants in “their” ipad. They’re ok with codea but maybe only running code that moves as a slow vector (ipda41001 i like your analogy).