TamsPalm – the Palm OS / web OS Blog

Pre owners have just received 13 further megabytes of webOS data – the latest update brings the little critter to version 1.3 and adds the following features:

Calendar
• Events created in your Google calendar—either in Calendar on your phone or in Google online—that contain a symbol or accented character in the event name can now synchronize. Previously, including a symbol or accented character in an event name prevented the event from synchronizing.
• Changes made to Google events on the phone now sync with Google online within a few minutes.
• The sync interval for Google events has been decreased from every few hours to every 15 minutes.

Clock
• If you create a weekday alarm on a weekend, the alarm sounds only on weekdays. Previously the alarm would sound on the weekend also.
Contacts
• Changes made to Google contacts on the phone now sync with Google online within a few minutes.
• The sync interval for Google contacts has been decreased from every few hours to every 15 minutes.

Email
• Power performance in areas where wireless coverage is sporadic or unavailable has been enhanced.
• Non-SSL Exchange ActiveSync (EAS) mail servers are now supported.
Other
• Miscellaneous updates for Email, Phone, and other applications.

As of now, nothing else is known – but seeing Palm release official “change logs” definitely is a nice touch…

Palm’s webOS application store is extremely open when it comes to stats – figures like the total number of apps and downloads can be accessed simply.

The folks at MediaLets did just that, and present the figure below:

In case you are interested – hit the link above for a huge load of extra info!

O’Reilly has just released chapter number eight of its webOS book:

The author describes the chapter as follows:

…

System services are those that are enabled by hardware features or provided by the Linux operating system. Hardware-enabled services include access to location services, and connection status. The OS provides alarms, sounds, power management, properties and time services.

As described in Chapter 7, the Mojo framework provides access to the System services, routing service requests to the specified services, and calling the application’s callback functions with the service response. As shown in Figure 8-1, all system services are actually managed by Linux-resident server processes. The servers receive service requests from the application and send messages back. The messages are routed to the application through the specified callback functions, whether fulfilling the request or providing a failure indication.

…

As usual: if anyone of you feels like taking a look, hit the link below:
http://my.safaribooksonline.com/9780596802097?tocview=true

Various web sites have seen the statement below – it was made by an official VodaFone Ireland employee, who then proceeded to delete it quickly afterwards:

As of now, we don’t know which carrier will carry the Pre in Europe. However, we now know that it won’t be VodaFone…

Apple’s iPhone initially was programmable only in JavaScript. Its apps ran on the server, and nobody had any problems. Palm’s Pre can also be programmed in JavaScript; but can run apps locally. Guess where its going? If not, enjoy the text below:

…

Palm’s standard apps — Messaging, Web, Photos, Music, Memos — they’re all written in Javascript. I was wrong about them writing their own apps in Java, but right about them being serious about JavaScript development.

Furthermore, the 3rd party apps are all there, too, in glorious sourcecode form.

…

While Java Bytecode and MSIL can both be decompiled with some effort, MSIL and JBC-based applications don’t ship in source code but rather binary form. JavaScript apps, on the other hand, drop in source code form…

Seing that the webOS is a small platform, Palm could theoretically have gone the way of ArianeSoft: translate the JavaScript to a proprietary form of bytecode. This would have led to faster execution speeds and eliminated IP-level theft:

.NET CF has recently gotten under fire because applications created with it are easily disassembled. Is this possible with PPL, too?
Not unless you know how to. There are encryption, compression involved and then you need to know how the undocumented PPL’s bytecodes works.

Unfortunately, none of this has happened so far. This means that all source code written for the Pre can be read by your competitors with minimal effort, thereby compromising not only your investment but possibly also your intellectual property (which can then be used on other platforms where the theft can not be proven easily).

Ideas, anyone?