Try looking into the media player (QuickTime) framework. We’ve built native apps that can call QuickTime objects and pass urls for static and streaming content to it, even overlay HTML over the streaming video. Let me go find where that lives.
@alvelda I mean we don’t get access to the h264 decoder, not that we can’t use a movie player controller. We don’t get low-level access to Apple’s h264 drivers.
As for client vs. server I’m not so worried about centralization, as I am interested in having server components that can make asynchronous interfaces between different nodes. Imagine a physics class where everyone is writing code to talk to the USB interface plugged into some lab sensors (another ask). I’d like for a student to be able to write some simple code to query the sensor, log the data, plot it, analyze it, and then make that data accessible to any other iPad in any school, as long as it is connected via IP. Posting it to a central server would be second best, but I would prefer an interface that could serve data from each iPad instance without central server support.
@simeon, understood, but access to the movie player object would be cool. Then I want an instance of the browser on top of that…
@alveda - so, in a nutshell, you want to not only be able to connect, but also to listen on a socket.
That’s another thing the http and higher APIs won’t do.
And yes - that’s something I could see using. (Sigh - that gets into some code I’d like to write, but have no hope of doing in codea - a background server. I would dearly love a tiny webserver that runs in the background on the ipad so that I could connect Safari to localhost and serve a little wiki or such)
@alvelda Your first use case sounds like an ideal use for the bluetooth multiplayer API. Zero configuration, easy to see all iPads in range, easy to send and receive data. It’s peer-to-peer networking built into iOS. It’s the most painless way to set it up.
Regarding movie players: Codea is for drawing graphics. Adding native UI elements such as a movie player and browser wouldn’t really fit, as they wouldn’t be mapped into the current transform matrix. If we were to support motion video (either through the camera or h264 decoded frames) it would be as a texture or fill type.
That description of a physics class is something that occurred to me when reading this discussion. It would be great to be able to have a couple of iPads connected so that one was connected to a big projector (and thus not mobile) and the other could be passed around the class for students to do something whereby they interact with whatever simulation is being run. (I’m thinking of an interactive Gaussian elimination app where one actually picks up the rows and manipulates the. via touch).
@Andrew I think that’s a great use, and one that would work well with the GameKit
@Bortels, this is the programming guide for GameKit’s peer-to-peer service: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/GameKit_Guide/GameKitConcepts/GameKitConcepts.html#//apple_ref/doc/uid/TP40008304-CH100-SW1
My multiplayer API above was intended to be a wrapper for that particular service. I think it offers the least hassle and greatest functionality for local connectivity.
Now, if our http API supported RESTful web services, would these two things be enough?
@bortels: exactly!
@simeon: I’m not sure about the Bluetooth option. That would limit access to people in the room. Ideally, I’d like kids all over the world (okay maybe start with kids at home) to be able to still interact with each other’s work…so I seem to end up back at a general http over TCP/IP interface.
On the movie player, the HTML5 interface in the browser element will actually support a broad range of transforms and filters. Maybe what we really need is just the browser object and maybe some way to overload the codes Lua commands in that context? I realize I’m trying to smash several layers of OSI stack together…not sure Ai even have an idea of how to do this. But it does appeal to my HTML5 fetish in general.
What we have now, in release, not in beta, with no sockets, is “enough”. If sockets never made it to the real world, I’d still be playing with Codea. Disappointed, but playing.
But I’m not aiming at “enough”, and I hope you aren’t either. I’d like to see, someday, Codea be a first-class choice for ipad development (first-class meaning you can mostly do anything you could do in any other programming language on any other platform, not meaning you could take things to the app store).
If I had a choice between ‘sockets’ and ‘http’ - I’d choose sockets, because if I can get sockets, I can build http on top of it, as you’ve shown. You don’t need http for sockets, but you do need sockets for http. Given a choice, my inclination is going to be to go with whatever gives me the most flexibility - and that’s sockets. Low level libraries are what I’m looking for - let the user-base build higher level APIs on top of those, reflecting what we want to use Codea for.
But, to be bluntly truthful - yes, a RESTful web API would support 96% of what I’d likely want to do. (I’d still really like to listen to a socket and accept connections - @alveda gave me a ton of new ideas suggesting that…)
To offer constructive criticism - I think when you label Codea as being “for” something with words like “prototype” or “graphics programming”, you limit yourself, and you limit Codea. Aiming at or concentrating on graphics is fine - but the really awesome thing is when people do things with Codea you didn’t expect.
I agree with what Bortels just said. Do the low-lying stuff that we can’t do. We’ll build stuff on top and you’ll be amazed at what we come up with.
You guys are exceptional users - creating extraordinary things. I think most users will prefer a higher level API to sockets. However, I’ll make sockets available for you. I won’t release them until a higher level API is in-place.
Here’s what we’ll keep:
socket
socket.tcp
socket.udp
socket.dns
socket.url
socket.mime (moved from global)
Here’s what we’ll drop:
socket.http
socket.ftp
socket.smtp
ltn12
Here’s what we’ll add
-- Replaces socket.http
network.get
network.post
-- GameKit API
multiplayer.* -- API to be developed
Any chance we can get OpenSSL and zlib in there? 