Palm's new OS finds the sweetest spot

If necessity is the mother of invention, maybe it helps to be really, really needy when you have to come up with something great. That would seem to apply to Palm, which was considered down and out when it was developing its new mobile operating system, webOS. But as further details of the system and development process emerged …

[Steven Dick]

OSGi

OSGi is, today, one of those trendy acronyms that no longer stands for anything. It's just OSGi.

OSGi did start in the embedded Java space, but if you write any plug-ins for the Eclipse development environment, then you're writing OSGi bundles as Eclipse is built upon OSGi.

All of the Java application servers are now talking about OSGi, with many of them using it under the hood in their latest versions.

As a server-side Java developer (myself and my team are using it), I see OSGi in the early stages of adoption with more developers talking about it rather than using it. Only time will tell if it will become mainstream for Java.

[Gareth Saunders]

Is it me...

... or was the iPhone/Pod Touch criticised for not having a 'full' API exposed, when Apple tried to push its own web app concept for v1.x.

Not that I am saying that this is a bad idea, but there does seem to be a dichotomy in the reception of these lightweight application platforms. A little consistency is always nice (and don't worry, Mr. Orlowski, it's not just you doing this).

[Stubbs]

Web Run Time

Of course there is nothing to stop other platforms from having a widget engine to create apps. Take Nokia’s Web Run Time for example.

[Craig]

BeOS

They should have just stuck BeOS on there.

[Anonymous Coward]

Good luck Palm

As an avid PalmOS user for many years I wish Palm all the best, and will probably get one just to support them (yes I am a *fanboy* :P )

[David Beers]

OSGi more than a buzz word for mobile Java

@Steven: OSGi may be a trendy acronym among server-side Java developers, but for mobile Java developers it answers some really serious deficiencies that the JCP has failed to address for years. Java ME MIDP's lack of a component model has created the worst kind of fragmentation and the many ways MIDP keeps mobile Java developers from leveraging all the innovation that is going on elsewhere in the software world has relegated it to "toy" status, despite the fact that it's on a billion phones and has such tantalizing potential. OSGi enables mobile Java environments to align with standards that server-side Java developers enjoy without imposing ever more bloated monolithic stacks. Honestly, for mobile developers it's like being let out of prison. I should add that the speculation that Palm is using OSGi or will have a Java SDK at all contains a good dose of wishful thinking. I think they'd be crazy not to, but that's about all the reason I had for supposing they've actually done so.

@Register: My last name is Beers, not "Pike." Since the Internet never forgets :-)

[Bug]

again...

@Gareth Saunders

Again, the different is iPhone was javascript run in Safari. This is being touted as javascript to interact with the operating system.

webOS is supposed to let you do something like

myMatches[]=system.addressbook.find("bill");

to search the address book on the phone.

Does it surprise you that most 1st person shooters and games are created in a languages similar to javascript with the engine being C? Same Idea

[fluffy]

Javascript has improved since iPhone 1.0

Now there are several excellent Javascript interpreters which support JIT, which means that it's actually quite possible to get quite good performance from it nowadays. Sure, it's not going to be as fast as C++ (or probably even as fast as JIT Java) but it'll still be pretty competitive.

Also, for network-bandwidth-heavy things like Jaiku (as mentioned in the article), it's not like the JS app has to individually process every byte of data - if they do something like implement a Socks server (like NetShare on the iPhone) there's very little heavy lifting that has to happen in the app itself. It'd just be passing large byte arrays around, for the most part.