MobileRead Forums - View Single Post

cervezas · 03-27-2006, 02:23 PM

Antoine:

The main two reasons this could come to market faster is that (1) Palm is rumored by a credible source to have been working on it even before PalmSource started working on Cobalt for Linux--some of which time has probably just been research, but still, they may have the jump on ACCESS; and (2) leaving out MAX, which is a public API, and having a native framework that is only for use internal to Palm saves a lot of time and effort. Public APIs are "contracts" with developers that you need to be able to keep for the long run. Private ones are still contracts you want to keep, but it's a lot easier to break them if the only clients are internal.

Surer:

You could be right about Palm developing the PIM apps as native applications. If we did find out they are doing that I would lean more toward the opinion that they are developing this framework as a public API for the long haul. I can't see a reason to make native PIM apps if the native API isn't going to be the new Palm OS SDK since PIM apps don't really benefit from having better multitasking nearly as much as the other apps I listed.

If Palm is trying to build an open Linux platform rather than a temporary life support system for Garnet it would mean we'd be a lot less likely to see that platform in any of the Treos coming out this year. And it would also mean that Palm is less likely to migrate to ALP in the future: their platform would truly be the new Palm OS for Linux, a project on the same order as ALP. The platform you outline is a lot less desperate than the one I outlined (at least if we amend it with the idea that the native API will be a published SDK for 3rd party developers). Perhaps Palm has done another magnificent hack on Garnet to make it comply with UMTS and thereby bought themselves enough time to do this platform right. If so, hats off to them and whoever they're partnering with to do it (it wouldn't happen without a major Linux partner like MontaVista, Trolltech or Wind River.)

As for Java, I generally agree that it's not a priority for Palm to have it on every device so, yes, the Java environment might not ship with the platform. But the Treos do support Java ME using IBM's Websphere Everyplace environment and I'd expect that to continue to be the case. Actually, with a Linux environment I'd say IBM might take a much closer look at partnering with Palm (or just some open source contributors) for an Eclipse eSWT and eRCP port. That's the cutting edge in mobile Java these days since Eclipse is all the rage in the Java world. See, part of the reason that Palm hasn't kept pushing on Java is that Garnet imposes some limits on the kind of Java environment that can be supported: the highly constrained CLDC/MIDP is the best you can do, whereas Symbian and Windows Mobile support CDC/Foundation Profile and Personal Profile--much closer to full-fledged Java SE.

As a developer I find it very interesting that the 68k API could become more like a standard (akin to J2ME) than a specific implementation. In other words, it might actually exist for some time on devices running both ALP and "Palm OS 7" devices from Palm. Nevertheless, we'd expect the two platforms to focus on the development of their native frameworks and for both users and developers to migrate fairly quickly over to those frameworks for the apps that they create and buy. Lots of opportunities looking at this from the standpoint of the growth of mobile Linux, but also plenty of problems with this kind of split of the "Palm" economy. If Palm is really doing what it looks like they are doing I hope they'll get involved with MLI and LiPS and help to form some standards for mobile Linux rather than just "going rogue."

Keep in mind, while I think it's fairly certain that Palm is doing some significant framework development with Linux, we really have no idea what that framework is for. It could have nothing at all to do with smartphones and be for a completely new product category. Palm could be quiet about ALP just because ALP for all intents and purposes doesn't even exist yet and they want to be cautious as they were with Cobalt. There are many unknowns and the stuff I'm presenting here is just what I see as a probable scenario based on rumors and job postings.

03-27-2006, 02:23 PM	#6
cervezas palm & java hacker Posts: 52 Karma: 251 Join Date: Oct 2005 Location: Manitou Springs, CO Device: Visor, T3, i500, iQue ...	Antoine: The main two reasons this could come to market faster is that (1) Palm is rumored by a credible source to have been working on it even before PalmSource started working on Cobalt for Linux--some of which time has probably just been research, but still, they may have the jump on ACCESS; and (2) leaving out MAX, which is a public API, and having a native framework that is only for use internal to Palm saves a lot of time and effort. Public APIs are "contracts" with developers that you need to be able to keep for the long run. Private ones are still contracts you want to keep, but it's a lot easier to break them if the only clients are internal. Surer: You could be right about Palm developing the PIM apps as native applications. If we did find out they are doing that I would lean more toward the opinion that they are developing this framework as a public API for the long haul. I can't see a reason to make native PIM apps if the native API isn't going to be the new Palm OS SDK since PIM apps don't really benefit from having better multitasking nearly as much as the other apps I listed. If Palm is trying to build an open Linux platform rather than a temporary life support system for Garnet it would mean we'd be a lot less likely to see that platform in any of the Treos coming out this year. And it would also mean that Palm is less likely to migrate to ALP in the future: their platform would truly be the new Palm OS for Linux, a project on the same order as ALP. The platform you outline is a lot less desperate than the one I outlined (at least if we amend it with the idea that the native API will be a published SDK for 3rd party developers). Perhaps Palm has done another magnificent hack on Garnet to make it comply with UMTS and thereby bought themselves enough time to do this platform right. If so, hats off to them and whoever they're partnering with to do it (it wouldn't happen without a major Linux partner like MontaVista, Trolltech or Wind River.) As for Java, I generally agree that it's not a priority for Palm to have it on every device so, yes, the Java environment might not ship with the platform. But the Treos do support Java ME using IBM's Websphere Everyplace environment and I'd expect that to continue to be the case. Actually, with a Linux environment I'd say IBM might take a much closer look at partnering with Palm (or just some open source contributors) for an Eclipse eSWT and eRCP port. That's the cutting edge in mobile Java these days since Eclipse is all the rage in the Java world. See, part of the reason that Palm hasn't kept pushing on Java is that Garnet imposes some limits on the kind of Java environment that can be supported: the highly constrained CLDC/MIDP is the best you can do, whereas Symbian and Windows Mobile support CDC/Foundation Profile and Personal Profile--much closer to full-fledged Java SE. As a developer I find it very interesting that the 68k API could become more like a standard (akin to J2ME) than a specific implementation. In other words, it might actually exist for some time on devices running both ALP and "Palm OS 7" devices from Palm. Nevertheless, we'd expect the two platforms to focus on the development of their native frameworks and for both users and developers to migrate fairly quickly over to those frameworks for the apps that they create and buy. Lots of opportunities looking at this from the standpoint of the growth of mobile Linux, but also plenty of problems with this kind of split of the "Palm" economy. If Palm is really doing what it looks like they are doing I hope they'll get involved with MLI and LiPS and help to form some standards for mobile Linux rather than just "going rogue." Keep in mind, while I think it's fairly certain that Palm is doing some significant framework development with Linux, we really have no idea what that framework is for. It could have nothing at all to do with smartphones and be for a completely new product category. Palm could be quiet about ALP just because ALP for all intents and purposes doesn't even exist yet and they want to be cautious as they were with Cobalt. There are many unknowns and the stuff I'm presenting here is just what I see as a probable scenario based on rumors and job postings.