Isn't the iPhone SDK coming due out right around February? And doesn't that support the iPod Touch as well as the iPhone?
Seems to me that you could combine what Google and Apple are doing in the handset space right now to achieve pretty much what you want...
(By the way, I've already been doing some of the specific things you're talking about with web apps designed to render on phones. There's a Java API (other languages too) for X10, and so you can write web apps tuned for handhelds that when used control the lights in your house. Add a handheld-tuned Wiki, a computer-controlled IR emitter, et cetera, glued to your web server with APIs in your favorite web app language and you can already to most of it.)
You know, it may not take a whole lot of work to get an Android runtime up and running on the iPhone once they open up the iPhone SDK. I read through the Android dev docs, and apps are written in Java. You don't directly call native code, you just have a JVM with libraries available to it. So it may not be all that hard to get a compatible runtime into a much wider variety of devices.
That would mean that you could code for the gPhone and deploy on the iPhone (or even iPod Touch), either by loading the runtime onto the iPhone first (cf. "Cedega"), or by bundling a stripped-down runtime into the iPhone version of the app (cf. "Cider").
That'd rock. That'd rock hard. I'd become an Android developer if things work out that way.
Holy crap, they bundled WebKit? I somehow missed that in all the hoopla.
That means that the gPhone web browser has the same rendering engine as the iPhone web browser, the one that's shared by Safari (and OmniWeb) on the desktop. It's going to get less and less safe for web developers to ignore that rendering engine...
If you read the HTML comments, you can see that it had to figure out that the path was "/html/gifts60r.phtml", and it concluded from that that the product ID it was looking for was "gifts60r". It did a search on that and then came up with a bunch of items that fit that category.
If you follow the link for the first one, you can see that the product detail page also derives the product ID from the URL directly, and renders content based on searches given that.
I still think incrementing (evolving) the early success of Roomba is the way to make robotics a permanent industry that gets us to what we all want: robot slaves without cruelty.
Speak for yourself! I'll pay extra for a robot that cries when I smack it.
I had just joined a startup company, "Hells's Kitchen Systems", or "hks.net". We were an e-commerce startup. Our main product was CCVS, a credit-card processing system for Linux and other versions of Unix. But our first product was a shopping mall written in PHP. Not a simple store, but a mall -- it could contain multiple stores, each of which had multiple departments, each of which had a variety of products.
So, the web content was driven from database searches. But we did not want it to look like that was the case -- we wanted it to look like a family of hand-crafted web sites.
So we did exactly what's described. We appended strings to the end of URLs, and parsed the URLs and used them to search in order to build the pages. People would go through an ordering process, and an order was composed and faxed to the warehouse so it could be fulfilled. It was meant to be a cheap way to get any company that could take catalog orders onto the web without forcing them to change their business processes too much.
It was originally written in PHP/FI2, and then ported to PHP3.
Two different stores that used the system made it into production and were up for years. I am going to wrack my brian to try to remember their names, and if I can, I'll find them on the wayback machine so I can point to them. I bet a bunch of my comments made it into the delivered HTML, and so we might be able to actually prove my claim.
So, even if apps require formal signing and they all cost money, I still kinda expect that one thing we'll get is IBM's WebSphere Everyplace Micro Environment.
It exists for PalmOS, it exists for Windows Mobile, it exists for other handhelds, and I imagine that both IBM and Sun would explode with joy at the possibility of getting it onto the iPhone and iPod Touch.
For those who don't know, this is IBM's J2ME/JavaME runtime for small systems. If you have Java on your PalmOS, Windows Mobile, or even many Linux handhelds, it's probably due to this being loaded on or embedded into it.
If we don't get that, maybe we'll get a port of the open-source reference implementation of JavaME:
It already builds for both ARM (current iPhone) and x86 (rumored future iPhone) instruction sets.
Either way, looks to me like once there's a general dev kit, a JVM isn't going to be too far off. Anyone want to make predictions about how long it'll take or what form it'll come in?
My understanding is that, yes, they're picking up FreeBSD jails. We'll see on the 26th, when the OS is formally released. I am expecting "man 2 jail" to start giving results after I install 10.5. We'll see.
App signing cannot require in all cases the involvement of AT&T.
Why?
AT&T is not involved with the iPod Touch or with European iPhones at all. Apple made a point out of saying this SDK is for both the iPhone and the iPod Touch. That's meaningful.
My prediction is that it'll be a lot like some Java handhelds. There will be a key repository. It will come with the public key of Apple and, for iPhones, for the carrier from which you currently get service. Developers will be issued a key pair, one to go onto the device they use for development, and one to sign the apps they're developing, but installing the pubic keys onto arbitrary devices will be non-trivial.
My prediction based on that is, anyone who cares about running a wide variety of apps will register as a developer and get a key pair, and freeware apps will have to be open source, because in order to get them signed correctly, people will have to compile them from source so that they're properly signed for their own devices.
If registering as a developer is cheap/free, I am not sure that's a bad thing...
Note that under security, there are adding app signing and sandboxing and improving certificate handling in the core of MacOS X.
That's exactly what they need in order to pull off what they aim to with the iPhone and iPod Touch SDK!
And improved VPN support and library randomization sure wouldn't hurt for a device like an iPhone. (Some people can't use IMAP at all unless they have VPN support.)
Maybe you're joking, but there's actually a point you're making that could at least be easily mistaken for a reasonable one.
The "right" solution is to make the standard layered. Define a mandatory core, optional extensions which can be implemented in a common manner, a system for proposing additional optional extensions, and a system for utilizing proprietary extensions.
Then you can wander from metaverse to metaverse, and your basic core will remain intact, but the level of fidelity and the types of things you can do can flicker up and down around you depending on the context.
There are two reasons this might happen. One is a good, smart reason. The other is a lame, stupid reason.
Good reason: genuine cost/benefit analysis. "We ran a check of our server logs, and conducted this other analysis (appendix attached), and supporting such-and-such would only benefit so-and-so percentage of our potential users; meanwhile, the cost for developing for this target is this much, and the cost for developing for this wider base is that much. Those are the figures, now decide what to do." "Okay, we aren't going to support Linux or PalmOS for clients right now, but we'll re-evaluate our supported client list again next quarter, as usual. Next agenda item?"
Bad reason: boneheads quoting third-hand statistics and FUD, and then not thinking or listening. "Why aren't we supporting MacOS and Linux?" "Stop being a troublemaker, you know nobody uses those, and it costs way too much to support them."
Both effects happen out in the real world. From the outside of the organizations involved, it's not always easy to determine which is going on.
The up-conversion makes PS2 games bearable on high definition displays.
That's a somewhat compelling argument for both of the people I know who have high definition displays. Not so much for me. Not so much for almost every one of my friends.
If I get a PS3, I will do nothing with it but play PS1, PS2, and PS3 games on an ordinary analog NTSC television set. It's just crazy expensive for that, right now. I'll think about it once it drops below $300 or so.
I don't know why people believe offline usage and local storage will be problems. My understanding is that there will be no problem. Just install the apps onto the phone's local filesystem and have it point its web renderer at that stuff.
Unrestricted networking, yes, I can see the networking having some restrictions. But almost all handsets sold in the US have restricted networking. I don't see this getting in the way of most app ideas.
They seem unlikely to me. They've said outright that AJAX apps can be visually indistinguishable from "native" apps. Seems certain to me that you'll be able to use JavaScript to make that stuff invisible.
If all the key iPhone functionality can be accessed via AJAX and/or flash (and it sounds like it can -- they've got JavaScript hooks for dialing and for diddling the address book and stuff, looks like), what significant advantage do people imagine a "more native" dev kit would have?
The only think that'll completely eliminate the viability of video in iTunes is something that can completely replace the functionality of video in iTunes.
When I get a video in iTunes, it's so that I can download it onto my video iPod, to watch it on the bus during my commute, or while waiting for my food at a restaurant, et cetera, et cetera.
I'll give you an example: Heroes. The web site lets you watch episodes for free. I've still bought some episodes via iTunes. Why? The web site used streaming video. I don't want to watch on my computer. I want to watch on my iPod, which doesn't have a net connection.
The most dangerous toy I've personally ever seen was the original Mr. Potato Head.
It didn't come with a potato. You used it with real potatos. It was a bunch of parts like eyes and a nose and arms and stuff, with long, sharp spikes on the other end. You'd drive them deep into actual tubers instead of some soft vinyl thing.
Slashdot Mirror
http://www.betaversion.org/~stefano/linotype/news/110/
Isn't Android open source?
Isn't the iPhone SDK coming due out right around February? And doesn't that support the iPod Touch as well as the iPhone?
Seems to me that you could combine what Google and Apple are doing in the handset space right now to achieve pretty much what you want...
(By the way, I've already been doing some of the specific things you're talking about with web apps designed to render on phones. There's a Java API (other languages too) for X10, and so you can write web apps tuned for handhelds that when used control the lights in your house. Add a handheld-tuned Wiki, a computer-controlled IR emitter, et cetera, glued to your web server with APIs in your favorite web app language and you can already to most of it.)
You know, it may not take a whole lot of work to get an Android runtime up and running on the iPhone once they open up the iPhone SDK. I read through the Android dev docs, and apps are written in Java. You don't directly call native code, you just have a JVM with libraries available to it. So it may not be all that hard to get a compatible runtime into a much wider variety of devices.
That would mean that you could code for the gPhone and deploy on the iPhone (or even iPod Touch), either by loading the runtime onto the iPhone first (cf. "Cedega"), or by bundling a stripped-down runtime into the iPhone version of the app (cf. "Cider").
That'd rock. That'd rock hard. I'd become an Android developer if things work out that way.
Holy crap, they bundled WebKit? I somehow missed that in all the hoopla.
That means that the gPhone web browser has the same rendering engine as the iPhone web browser, the one that's shared by Safari (and OmniWeb) on the desktop. It's going to get less and less safe for web developers to ignore that rendering engine...
FOUND IT!
One of the companies that used our stuff back then was Felissimo. Here's a URL for a file that was produced by my software.
http://web.archive.org/web/19980514092506/http:/felissimo.com/html/gifts60.htm
If you read the HTML comments, you can see that it had to figure out that the path was "/html/gifts60r.phtml", and it concluded from that that the product ID it was looking for was "gifts60r". It did a search on that and then came up with a bunch of items that fit that category.
If you follow the link for the first one, you can see that the product detail page also derives the product ID from the URL directly, and renders content based on searches given that.
Now... what do I do with this info?
Speak for yourself! I'll pay extra for a robot that cries when I smack it.
At first, I thought the title was "Personal Robots Form Valley Startup".
Now that would have been an interesting story...
Hm, I see that what I was doing was not precisely the same as what's claimed. But is it enough to help invalidate the patent?
I do think that what they describe is very clearly obvious given what I was doing back then.
I was doing this in 1996.
I had just joined a startup company, "Hells's Kitchen Systems", or "hks.net". We were an e-commerce startup. Our main product was CCVS, a credit-card processing system for Linux and other versions of Unix. But our first product was a shopping mall written in PHP. Not a simple store, but a mall -- it could contain multiple stores, each of which had multiple departments, each of which had a variety of products.
So, the web content was driven from database searches. But we did not want it to look like that was the case -- we wanted it to look like a family of hand-crafted web sites.
So we did exactly what's described. We appended strings to the end of URLs, and parsed the URLs and used them to search in order to build the pages. People would go through an ordering process, and an order was composed and faxed to the warehouse so it could be fulfilled. It was meant to be a cheap way to get any company that could take catalog orders onto the web without forcing them to change their business processes too much.
It was originally written in PHP/FI2, and then ported to PHP3.
Two different stores that used the system made it into production and were up for years. I am going to wrack my brian to try to remember their names, and if I can, I'll find them on the wayback machine so I can point to them. I bet a bunch of my comments made it into the delivered HTML, and so we might be able to actually prove my claim.
So, even if apps require formal signing and they all cost money, I still kinda expect that one thing we'll get is IBM's WebSphere Everyplace Micro Environment.
It exists for PalmOS, it exists for Windows Mobile, it exists for other handhelds, and I imagine that both IBM and Sun would explode with joy at the possibility of getting it onto the iPhone and iPod Touch.
For those who don't know, this is IBM's J2ME/JavaME runtime for small systems. If you have Java on your PalmOS, Windows Mobile, or even many Linux handhelds, it's probably due to this being loaded on or embedded into it.
If we don't get that, maybe we'll get a port of the open-source reference implementation of JavaME:
http://en.wikipedia.org/wiki/PhoneME_(software)
It already builds for both ARM (current iPhone) and x86 (rumored future iPhone) instruction sets.
Either way, looks to me like once there's a general dev kit, a JVM isn't going to be too far off. Anyone want to make predictions about how long it'll take or what form it'll come in?
My understanding is that, yes, they're picking up FreeBSD jails. We'll see on the 26th, when the OS is formally released. I am expecting "man 2 jail" to start giving results after I install 10.5. We'll see.
App signing cannot require in all cases the involvement of AT&T.
Why?
AT&T is not involved with the iPod Touch or with European iPhones at all. Apple made a point out of saying this SDK is for both the iPhone and the iPod Touch. That's meaningful.
My prediction is that it'll be a lot like some Java handhelds. There will be a key repository. It will come with the public key of Apple and, for iPhones, for the carrier from which you currently get service. Developers will be issued a key pair, one to go onto the device they use for development, and one to sign the apps they're developing, but installing the pubic keys onto arbitrary devices will be non-trivial.
My prediction based on that is, anyone who cares about running a wide variety of apps will register as a developer and get a key pair, and freeware apps will have to be open source, because in order to get them signed correctly, people will have to compile them from source so that they're properly signed for their own devices.
If registering as a developer is cheap/free, I am not sure that's a bad thing...
Look at the SDK announcement. Then look at the list of Leopard features here:
http://www.apple.com/macosx/features/300.html
Note that under security, there are adding app signing and sandboxing and improving certificate handling in the core of MacOS X.
That's exactly what they need in order to pull off what they aim to with the iPhone and iPod Touch SDK!
And improved VPN support and library randomization sure wouldn't hurt for a device like an iPhone. (Some people can't use IMAP at all unless they have VPN support.)
Maybe you're joking, but there's actually a point you're making that could at least be easily mistaken for a reasonable one.
The "right" solution is to make the standard layered. Define a mandatory core, optional extensions which can be implemented in a common manner, a system for proposing additional optional extensions, and a system for utilizing proprietary extensions.
Then you can wander from metaverse to metaverse, and your basic core will remain intact, but the level of fidelity and the types of things you can do can flicker up and down around you depending on the context.
There are two reasons this might happen. One is a good, smart reason. The other is a lame, stupid reason.
Good reason: genuine cost/benefit analysis. "We ran a check of our server logs, and conducted this other analysis (appendix attached), and supporting such-and-such would only benefit so-and-so percentage of our potential users; meanwhile, the cost for developing for this target is this much, and the cost for developing for this wider base is that much. Those are the figures, now decide what to do." "Okay, we aren't going to support Linux or PalmOS for clients right now, but we'll re-evaluate our supported client list again next quarter, as usual. Next agenda item?"
Bad reason: boneheads quoting third-hand statistics and FUD, and then not thinking or listening. "Why aren't we supporting MacOS and Linux?" "Stop being a troublemaker, you know nobody uses those, and it costs way too much to support them."
Both effects happen out in the real world. From the outside of the organizations involved, it's not always easy to determine which is going on.
If I get a PS3, I will do nothing with it but play PS1, PS2, and PS3 games on an ordinary analog NTSC television set. It's just crazy expensive for that, right now. I'll think about it once it drops below $300 or so.
Hm... what do plants grow in, again?
My first reaction was, "what do white people have against the pentagon? They're the ones that run the military/industrial complex to begin with!".
I don't know why people believe offline usage and local storage will be problems. My understanding is that there will be no problem. Just install the apps onto the phone's local filesystem and have it point its web renderer at that stuff.
Unrestricted networking, yes, I can see the networking having some restrictions. But almost all handsets sold in the US have restricted networking. I don't see this getting in the way of most app ideas.
They seem unlikely to me. They've said outright that AJAX apps can be visually indistinguishable from "native" apps. Seems certain to me that you'll be able to use JavaScript to make that stuff invisible.
Doesn't follow.
If all the key iPhone functionality can be accessed via AJAX and/or flash (and it sounds like it can -- they've got JavaScript hooks for dialing and for diddling the address book and stuff, looks like), what significant advantage do people imagine a "more native" dev kit would have?
That's like asking if Lockheed-Martin is out of touch with the average automobile user.
The only think that'll completely eliminate the viability of video in iTunes is something that can completely replace the functionality of video in iTunes.
When I get a video in iTunes, it's so that I can download it onto my video iPod, to watch it on the bus during my commute, or while waiting for my food at a restaurant, et cetera, et cetera.
I'll give you an example: Heroes. The web site lets you watch episodes for free. I've still bought some episodes via iTunes. Why? The web site used streaming video. I don't want to watch on my computer. I want to watch on my iPod, which doesn't have a net connection.
I'm an Integrater from about 10am to about 4pm on work days, and a Segmentor the rest of the time.
The most dangerous toy I've personally ever seen was the original Mr. Potato Head.
It didn't come with a potato. You used it with real potatos. It was a bunch of parts like eyes and a nose and arms and stuff, with long, sharp spikes on the other end. You'd drive them deep into actual tubers instead of some soft vinyl thing.
Now that was a dangerous toy.