Don't get too excited about sockets... (Changed my mind)

Apple might not approve it in the app store. One of us really smart ones (cough cough Bortels and a few other people) might create a remote computer that we could use to emulate computers on our iPad. If this is not true please let me know. Codea is already on the verge of possible getting pulled. I don’t mean to pop your bubbles, but I’d rather knowing that this isn’t coming than have Two Lives Left code that feature, get our hopes up, and have the app rejected. If this isn’t coded, I know that coding for BlueTooth will be allowed in the app store.
P.S. Just for the fun of it, I wanted to mention this video I ran across. I haven’t had the time to try it but… Click Here.

Yes, sockets have not been submitted to Apple for this reason. We may reinclude them in the future, but the feature would have to make it in with Apple’s approval.

disallowing internet conectivity altogether because it can be misused seems crazy. I mean browsers can download code too - anything that can connect to anything can download code. Apple would have to restate the rules as, “programming enviroments cant have connectivity”.

It’s a tricky question whether, when introducing sockets, you ask Apple about this misuse case of sockets specifically, but there’s no doubt that sockets can add a lot of value even if one were somehow prevented from downloading code.

Yeah it’s more about policy than technical merit.

The security policy on iOS is that the only remotely downloaded code that can be executed comes through the App Store (reviewed by humans) and Apple’s javascript engine (Safari). This policy lets them focus on securing only two paths through which users can execute code on their device.

Lua, running inside a sandboxed .app package as it does in Codea, is pretty harmless. But the policy regulates executable / interpreted code, and so it falls under that policy. Despite the fact that it is very unlikely to pose a security threat due to the .app sandboxing.

So - I’ve suggested it before, perhaps this will let us work around it a bit - embed javascript in Lua, or in Codea as a co-language. Point being - if they allow javascript to access the web, fine - we’ll let javascript do that, and use it as a go-between. There are some things I want to do that it can’t (listen on a socket being the big one - that means we’ll need a server to mediate, no peer to peer), but again being able to get a URL, while not perfect, still is 90% of what I’d use sockets for, and the rest can wait until it doesn’t ruffle Apple’s feathers.

Stupid and roundabout? Yep. But I wanna be able to download big data (fonts, images, and real-world data) and use it in my programs, and if we have to do a special dance - well, I’ll put my dancin’ shoes on!

If they balk about being able to http download code and then loadstring() - well, that’s what javascript is. We promise we won’t make Flash. Really.

Well, now they also allow unreview lua code. You’re probably more frustrated about the restrictions than anyone else (although i’m sure you expected it going in) but point is i think the argument for sockets can be made in a way that’s disconnected from the discussion about downloading code.

One idea whould be to add sockets and remove loadstring. Then we’ll write a lua interpreter in codea so we can get around it :slight_smile:

I’ve considered just that! loadstring (now load) is useful for data marshall/unmarshall - but NOT essential. You just have to write code to work around it, loaders and so on. But sockets - you can’t do what you want to do without em. If it comes to either/or - I’d drop load() in a heartbeat.

Fact of the matter is, that is, to a large extent, why Apple had to dump “no interpreters” - it’s an unrealistic expectation. Does you code set up a state machine, and proceed from state to state? Congratulations - you’re interpreting, in a very rudimentary way. I would hazard to say that there is no really significant code in the app store that doesn’t have some rudimentary interpreter (in the aspect of “using data to direct code execution”) in it somewhere; it’s just a really useful, really common technique. And when you get into the savings in dev time from embedding Lua (or Unity or any of these other frameworks)… “no interpreters” was doomed (as I think “no outside code” will be, eventually…)

So yes - if we have to jettison load() to get sockets… silly, but I can live with it. I’ve seen sillier.

Sockets! Sockets!

I think in the end if they wont approve something like that is becaused they want to limit the features (should you be able to write an rss reader? Weather tracker? Stock whatver?) than about running unreview code. Ie it’s about fear of a shadow app store.

I’d rather have sockets and no load function that a load function and no sockets. There are so many cool visualisations we could write if we can grab data from the web.

As a Codea user, I also want sockets badly. But c’mon, let’s be fair. Try to think what if we’re on the Apple position? Having an app like Codea in the app store is already a threat to some extent. Yet to let it has advance features. Take a look at @ruilov’s pacman game, for example. With Codea, you got it for free (with the source code!) while the official licensed game will cost you $5! There are TONS of casual games that you may get or make yourself for free with Codea. Perhaps it won’t cause Apple any direct loss, but it will hurt many third party app developers. So, I don’t really expect socket will got through Apple approval, though I want it too. But I do expect better and more complete drawing APIs plus the email code sharing. I can live with those, happily in fact. :slight_smile:

If I was in apple’s position, something like Codea would come with the iPad - stock. And you’d be able to easily publish to the moderated app store. And jailbreak would be called “developer mode” and would be supported with a switch in settings.

There are less draconian ways for apple to achieve its goal of a safe app store.

This is all DRM - the manufacturer wants to control what the end user can or can’t do with what we paid for. It’s never beneficial to the end user, which is me. It might have been semi kinda justified on low bandwidth cell phone carriers - it has no place on my iPad using my wireless network. Apple’s business model is Apple’s problem, not mine.

@bee: I think sockets help in this case. Currently Codea is mostly a game prototyping tool. But with access to data sources on the Internet it can be pitched more like Processing: as a tool for visualising data in artistic ways.

Wow. That was a strong response. I think @Simeon might want to contact apple to see if they will allow it in the app store. If not, maybe Two Lives Left might host a muti-player server where we could create a key that other iPads could connect to and see open games. Two Lives Left could also allow us to make BlueTooth games.

If apple disallows network connectivity, but allows Bluetooth - I will share executable code via bluetooth, to prove the point. Sadly - that’s not what I want to do - I want to write games where I go to a server to get the other players moves and post my own (or write utility code, yeah, I’m weird). But if apple prevents that… Idle hands.

I absolutely agree with you @Bortels. I want to write ultility code too.

You know, I think about it more, to notice that iLuaBox is noticed by apple, and uses Sockets, SQL, and GUI. If only apple would call you back. You’d think that the iLuaBox developers are paying apple…

What does the iOS Submission guidlines say about accessing the Internet? We don’t even have LoadString(str) (do we?). And did I mention file IO in iLuaBox? X(

We do have loadstring(). Does iLuaBox disable loadstring()? If they do, they should be allowed to use sockets as none of the code can then be executed. If they allow loadstring() and sockets then they are violating the policy.

Yes, they do. They have not altered te Lua language at all. Instead, they’ve added things line Sockets, SQL, Vox, ect. @Simeon - Try iLuaBox lite. I use it just to use their offline lua documentation (wich would be nice for Codea) and see some thins that could be added to Codea. You might take a look this. Just some ideas. You can find Simply Lua for free here.

Out of curiosity - Can you do file IO over te Internet through sockets? That would be hazardous. Just imagine apple’s reaction.