<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Developing For Palm webOS: Free Book Chapter</title>
	<atom:link href="http://prepoint.wordpress.com/2009/02/16/developing-for-palm-webos-free-book-chapter/feed/" rel="self" type="application/rss+xml" />
	<link>http://prepoint.wordpress.com/2009/02/16/developing-for-palm-webos-free-book-chapter/</link>
	<description></description>
	<lastBuildDate>Mon, 18 Oct 2010 19:41:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: ramin</title>
		<link>http://prepoint.wordpress.com/2009/02/16/developing-for-palm-webos-free-book-chapter/#comment-141</link>
		<dc:creator><![CDATA[ramin]]></dc:creator>
		<pubDate>Mon, 16 Feb 2009 21:55:49 +0000</pubDate>
		<guid isPermaLink="false">http://prepoint.wordpress.com/?p=575#comment-141</guid>
		<description><![CDATA[Chrome could be turned into an app interface, but they&#039;ll have to add a bunch of plugins to expose OS services to Javascript. Then you have to package the whole thing so an app that consists of multiple HTML, CSS, JS, and image files can be put into a single downloadable bundle, then sign the whole thing so developers can be identified and paid for it. Instead, Android chose to go the route of the Java app. So instead of the browser becoming the engine through which apps run, the embedded Java VM becomes one. 

The Java API is much richer than the vanilla Javascript API. My guess is Mojo is all about adding support for Java-type APIs into Javascript.

The WebOS approach isn&#039;t panacea either. Be curious if they create a &#039;compiler&#039; that converts JS into binary code (app developers may  get nervous if they have to ship their app source code with each copy). Java compiles into bytecode as does Objective-C. It&#039;s easy to decompile, but it offers a bit of assurance to developers. 

Also, there&#039;s the question of an honest-to-goodness resolution-independent UI. If you&#039;re planning on supporting multiple devices, then an app built for 320x480 may not scale well up to 600x800. If you use lots of JPG and PNG files in your interface, it&#039;ll look like crap when it&#039;s blithely scaled up. If you require high-rez artwork, then your apps become bloated. So maybe you do vector graphics, but that can be slow. It&#039;s a big problem and if they don&#039;t solve it upfront, it can mean lots of pain down the line.

And let&#039;s not even start with access to OpenGL for 3D gaming.

So yeah, they make a a lot of claims. We&#039;ll see how it turns out.]]></description>
		<content:encoded><![CDATA[<p>Chrome could be turned into an app interface, but they&#8217;ll have to add a bunch of plugins to expose OS services to Javascript. Then you have to package the whole thing so an app that consists of multiple HTML, CSS, JS, and image files can be put into a single downloadable bundle, then sign the whole thing so developers can be identified and paid for it. Instead, Android chose to go the route of the Java app. So instead of the browser becoming the engine through which apps run, the embedded Java VM becomes one. </p>
<p>The Java API is much richer than the vanilla Javascript API. My guess is Mojo is all about adding support for Java-type APIs into Javascript.</p>
<p>The WebOS approach isn&#8217;t panacea either. Be curious if they create a &#8216;compiler&#8217; that converts JS into binary code (app developers may  get nervous if they have to ship their app source code with each copy). Java compiles into bytecode as does Objective-C. It&#8217;s easy to decompile, but it offers a bit of assurance to developers. </p>
<p>Also, there&#8217;s the question of an honest-to-goodness resolution-independent UI. If you&#8217;re planning on supporting multiple devices, then an app built for 320&#215;480 may not scale well up to 600&#215;800. If you use lots of JPG and PNG files in your interface, it&#8217;ll look like crap when it&#8217;s blithely scaled up. If you require high-rez artwork, then your apps become bloated. So maybe you do vector graphics, but that can be slow. It&#8217;s a big problem and if they don&#8217;t solve it upfront, it can mean lots of pain down the line.</p>
<p>And let&#8217;s not even start with access to OpenGL for 3D gaming.</p>
<p>So yeah, they make a a lot of claims. We&#8217;ll see how it turns out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mikecane</title>
		<link>http://prepoint.wordpress.com/2009/02/16/developing-for-palm-webos-free-book-chapter/#comment-140</link>
		<dc:creator><![CDATA[mikecane]]></dc:creator>
		<pubDate>Mon, 16 Feb 2009 21:32:10 +0000</pubDate>
		<guid isPermaLink="false">http://prepoint.wordpress.com/?p=575#comment-140</guid>
		<description><![CDATA[@raimn &amp; jeff: Thanks for the partition expertise.  That makes sense now.

If browser-centric cellphones are to be the future, what will Google do vis-a-vis Android and Chrome?  Why any need for Android if Chrome could be the basis of it all?]]></description>
		<content:encoded><![CDATA[<p>@raimn &amp; jeff: Thanks for the partition expertise.  That makes sense now.</p>
<p>If browser-centric cellphones are to be the future, what will Google do vis-a-vis Android and Chrome?  Why any need for Android if Chrome could be the basis of it all?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://prepoint.wordpress.com/2009/02/16/developing-for-palm-webos-free-book-chapter/#comment-135</link>
		<dc:creator><![CDATA[Jeff]]></dc:creator>
		<pubDate>Mon, 16 Feb 2009 20:57:44 +0000</pubDate>
		<guid isPermaLink="false">http://prepoint.wordpress.com/?p=575#comment-135</guid>
		<description><![CDATA[File partitions:
It&#039;s not very surprising that there are multiple partitions (and note it says &quot;ext3 filesystem for the internal (private) file partitions&quot; &lt;-- potentially multiple ext3 file partitions.  Linux typically will have multiple file partitions (eg, a root partition, a /boot partition, a swap partition, etc).  ext3 has many advantages over Fat32 and therefore makes sense to use in the main OS, but Fat32 makes a lot of sense for the media partition since that what is industry-wide supported.

Different resolutions:
From many screenshots I&#039;ve seen, the main screen looks like it automatically and dynamically resizes as notifications come in.  Example:  Figure 8 in the Chapter 1 of the WebOS overview shows even the card view being shrunk down due to 3 dashboards at the bottom.  And then each of the cards themselves are dynamically sized for this new screensize.   So it seems the different resolutions will come very easy to the WebOS.

Another noteworthy mention is the &quot;with or without keyboards&quot; - that would have to mean there is a soft keyboard available.  I have not seen that mentioned anywhere, but very much wondered if there would be one.  Seems like a soft keyboard could come in very handy at times (such as when holding the device in landscape mode).

Everything running in a browser:
It makes sense with the Mojo toolkit that everything runs on some sort of a browser framework. Or maybe a better analogy is that everything is running from a sort of web application server running on the device.]]></description>
		<content:encoded><![CDATA[<p>File partitions:<br />
It&#8217;s not very surprising that there are multiple partitions (and note it says &#8220;ext3 filesystem for the internal (private) file partitions&#8221; &lt;&#8211; potentially multiple ext3 file partitions.  Linux typically will have multiple file partitions (eg, a root partition, a /boot partition, a swap partition, etc).  ext3 has many advantages over Fat32 and therefore makes sense to use in the main OS, but Fat32 makes a lot of sense for the media partition since that what is industry-wide supported.</p>
<p>Different resolutions:<br />
From many screenshots I&#8217;ve seen, the main screen looks like it automatically and dynamically resizes as notifications come in.  Example:  Figure 8 in the Chapter 1 of the WebOS overview shows even the card view being shrunk down due to 3 dashboards at the bottom.  And then each of the cards themselves are dynamically sized for this new screensize.   So it seems the different resolutions will come very easy to the WebOS.</p>
<p>Another noteworthy mention is the &#8220;with or without keyboards&#8221; &#8211; that would have to mean there is a soft keyboard available.  I have not seen that mentioned anywhere, but very much wondered if there would be one.  Seems like a soft keyboard could come in very handy at times (such as when holding the device in landscape mode).</p>
<p>Everything running in a browser:<br />
It makes sense with the Mojo toolkit that everything runs on some sort of a browser framework. Or maybe a better analogy is that everything is running from a sort of web application server running on the device.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ramin</title>
		<link>http://prepoint.wordpress.com/2009/02/16/developing-for-palm-webos-free-book-chapter/#comment-134</link>
		<dc:creator><![CDATA[ramin]]></dc:creator>
		<pubDate>Mon, 16 Feb 2009 20:45:47 +0000</pubDate>
		<guid isPermaLink="false">http://prepoint.wordpress.com/?p=575#comment-134</guid>
		<description><![CDATA[A few points:

- The two file partitions make sense. The ext3 one is for internal use since it&#039;s an OS-only playground. The FAT32 is there so when you connect the device to USB on a desktop or laptop, it shows up as a regular file system that is supported by just about every OS out there so you can copy files/media back and forth. This way you don&#039;t need any special drivers installed to access the device.

- That iPhone video app is only for jailbroken apps. It sounds like core webOS supports video/audio capture at the OS-level, but they just aren&#039;t exposing the API to developers yet. That may be a timing thing or a matter of performance tuning. Video capture requires pretty hefty computing power to compress the content, which may interfere with background apps. My guess is they don&#039;t want to push it out until they&#039;ve had a chance to optimize and tune the OS.

- &#039;It makes it sound as if everything is running in a browser. Is it?&#039; 

Yup. It means that we&#039;ve come full-circle to where people kept saying Netscape would take over the OS and do away with desktop-only apps. Of course, it didn&#039;t happen because they wussed out. But essentially what you have is a browser *runtime engine* as the public face of your operating system desktop/launcher service. Imagine each app on the Palm as a desktop browser tab, but each running simultaneously. 

The difference between a desktop app and a browser-based app today is basically whether one is interpreted (Javascript) vs. compiled, and how much of the local system&#039;s services you can access. A desktop app has full access to things like raw networking, database, filesystem, multi-threading and background services, whereas a browser doesn&#039;t. It sounds like what Palm&#039;s done is expose some or all of these types of services to the browser via Javascript. The question is how much will they expose and how can they keep it secure from snooping malware downloaded from the web. It&#039;s not a new idea. MS has supported browser apps in IE for a long time. Konqueror (now Yahoo widgets) is based on similar technology and Apple took baby-steps toward this with Dashcode, but didn&#039;t go all the way. These guys look to be pushing it the farthest.

The chapter is just a teaser. They&#039;re dribbling it out to build interest (and obviously, it&#039;s working ;-) But it raises a lot of technical questions that remain to be answered.]]></description>
		<content:encoded><![CDATA[<p>A few points:</p>
<p>- The two file partitions make sense. The ext3 one is for internal use since it&#8217;s an OS-only playground. The FAT32 is there so when you connect the device to USB on a desktop or laptop, it shows up as a regular file system that is supported by just about every OS out there so you can copy files/media back and forth. This way you don&#8217;t need any special drivers installed to access the device.</p>
<p>- That iPhone video app is only for jailbroken apps. It sounds like core webOS supports video/audio capture at the OS-level, but they just aren&#8217;t exposing the API to developers yet. That may be a timing thing or a matter of performance tuning. Video capture requires pretty hefty computing power to compress the content, which may interfere with background apps. My guess is they don&#8217;t want to push it out until they&#8217;ve had a chance to optimize and tune the OS.</p>
<p>- &#8216;It makes it sound as if everything is running in a browser. Is it?&#8217; </p>
<p>Yup. It means that we&#8217;ve come full-circle to where people kept saying Netscape would take over the OS and do away with desktop-only apps. Of course, it didn&#8217;t happen because they wussed out. But essentially what you have is a browser *runtime engine* as the public face of your operating system desktop/launcher service. Imagine each app on the Palm as a desktop browser tab, but each running simultaneously. </p>
<p>The difference between a desktop app and a browser-based app today is basically whether one is interpreted (Javascript) vs. compiled, and how much of the local system&#8217;s services you can access. A desktop app has full access to things like raw networking, database, filesystem, multi-threading and background services, whereas a browser doesn&#8217;t. It sounds like what Palm&#8217;s done is expose some or all of these types of services to the browser via Javascript. The question is how much will they expose and how can they keep it secure from snooping malware downloaded from the web. It&#8217;s not a new idea. MS has supported browser apps in IE for a long time. Konqueror (now Yahoo widgets) is based on similar technology and Apple took baby-steps toward this with Dashcode, but didn&#8217;t go all the way. These guys look to be pushing it the farthest.</p>
<p>The chapter is just a teaser. They&#8217;re dribbling it out to build interest (and obviously, it&#8217;s working ;-) But it raises a lot of technical questions that remain to be answered.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
