First off it’s necessary to understand how businessy folks view open source. I have no idea how many of you who read this blog were around for it, but this was a huge raging debate in the early 2000s. How could it possibly make sense for a company to just give away something that it had sunk a huge number of hours into, and potentially represented some significant chunks of intellectual property? The argument that really won the day centered on a concept called commoditizing your compliments. See this blog posting from Joel Spolsky for a bit of background on the economic principle. In terms of software it means giving away the stuff that won’t make you much money so you can make more money on the stuff with good margins. If anyone out there can make an alternative argument for why HP would open up the OS have at it. But I’m going to stick with the assumption that they’re positioning for a market shift in which the stewardship of the mobile OS itself is a commoditized low-value position.

So what’s the complement of a ‘platform designed from the ground up to be mobile, cloud-connected and scalable‘? Traditionally hardware has been the mainstay for HP. And it would make a kind of sense if they were looking to open up the OS and have folks integrate their own platform components in order to be able to make more hardware work together. They could be looking at the suite of iPad, iPhone, Apple TV, and iTunes and be thinking “Uh oh, Apple is starting to lock up the whole electronics space though integrated media components.” Which means if they want to keep playing in those markets they have to be able to catalyze a similarly optimized delivery channel if they want to keep a seat at the table. Possible. But I don’t think it’s the most likely one.

Another complement to webOS would be the stuff sitting on the other side, the cloud-connected part. That end would certainly line up with the software is eating the world idea that Marc (one of their board members) has been putting forth. Plus, it’s generally a bad idea to attack someone head-on when they’re in the kind of position of power that Apple is in. You try to look down the line to where their model extends and try to find a weakness. And while Apple has been fantastic on the merchandising side of the iTunes/App Store world, generally speaking their efforts to expand their cloud service offerings have fallen flat. If I were backed into a corner and forced to try to find a gap in the armor when competing with Apple, it’s the place I would go.

Since the full webOS stack is actually Linux under the hood, I assume it has an opportunity to capture a chunk of the Linux embedded system market the same was as Android has. As someone who spent way more time than I care to remember configuring and rebuilding Midori systems, I assume the more we can do on that part of the market the better. My fear though is that this opening of the platform is really just an attempt to try to get some free development. I’m sure that the folks involved at the top (like Marc) genuinely have a vision for everyone benefitting from opening up webOS, however it’s really easy to spoil an open source community down in the details even if your heart is in the right place.

If I put my rose colored glasses on and try to look into the future for webOS I see a future where the inherently web-connected OS manages to pull us out of this siloed mobile experience we’ve ended up in. It takes the best of what we’ve learned about putting services together as “apps” and reapplies that to the open web distribution model, and mixes in the deep platform capabilities from Android (for instance, I can write an app that accesses call log info. iOS GAH!).

However, to end up at that future we need an awesome technical platform AND distribution power. Products don’t win in market just for being the most technically awesome hacks. Otherwise we would all still be running BeOS today ;-) Unless there are a bunch of devices out in market running webOS it doesn’t make sense for third party developers to target the platform. And without a bunch of third party developers to write apps it’s hard to get a bunch of devices out into market (no one wants a phone without apps any more). So while I see a lot of awesome stuff that webOS COULD be, I still don’t see an obvious way to take it from where it is to where it needs to be. I don’t disagree with the open sourcing of the platform in general. It may be the right step along a roadmap. But because I have no idea what that roadmap is, I remain underwhelmed.

The README has info about how to output bookmarks in a form that the shim will understand. This is just initial hackery, not a real project yet. I just figured I would share it cause, well, taking some JSON and syncing it to the default browser bookmarks just seemed like the kind of thing other people might want to play with. If you turn on install from unknown sources you can download my prebuilt binary if you’re not into the whole Android development thing. Who knows, once I clean it up some I might even upload it to the market. There’s more hackery to be done first. Firefox Sync, I’m looking at you.

It’s too bad bookmarklets don’t work too well in the default Android browser otherwise there would be some much more obvious fun to be had.

Here’s an example of fetching the most recent unread messages for an account and writing out the subjects into a text buffer:

ContentResolver cr = getContentResolver();
Cursor unread = cr.query(Uri.parse("content://gmail-ls/conversations/xxxxxx@gmail.com"), null, "label:^u", null, null);
unread.moveToFirst();
int subjectIdx = unread.getColumnIndex("subject");
 
TextView tv = (TextView) findViewById(R.id.buffer);
do {
    String subject = unread.getString(subjectIdx);
    tv.append(subject + "\n");
} while (unread.moveToNext());

• export CFLAGS=’-fno-common -arch i386′
• export LDFLAGS=’-arch i386′
• export CXXFLAGS=’-fno-common -arch i386′
• pecl install xdebug

At first I tried some forms that included both architectures and some optimization flags cause I saw examples of that floating around online (ie. CFLAGS=’-O3 -fno-common -arch i386 -arch x86_64′). But that also was just faulting out on me. Checking the other modules in the Zend binaries they’re straight i386 architecture. I don’t do a lot of remote debugging, but it’s nice to have the option.

Lots of folks have been pining for a system that mashes together the best parts of the app store model with the good parts of the web. There’s lots of stuff that doesn’t work so well with the app stores (someone else telling you what you can release, having to filter all your releases through someone else in order to get them out to market, a lack of crosslinking and organic discovery). But the app stores have managed to provide a level of success in mobile that’s also pushed the boundary quite a bit. They provide payment mechanisms that seem to work much better for developers than previous attempts have, and they’ve gathered together a critical mass of users so that the folks who do see success see it at a significant level. We’ve gone through the native apps vs web apps argument in the past and touched on the app store vs web distribution issues as part of that.

So as far as putting a stake in the ground and trying to move us toward that model of app development, fantastic! Happy to see the effort. There are some parts I need to poke around with a bit to understand better. There’s a section about mobile usage that touches on offline applications, which I think is going to be one of the most major issues. It’s not immediately obvious to me if we could get apps installed via this mechanism to appear as icons on the iOS homescreen. Folks like OpenAppMkt have their method, which seems to be detecting the launch type and asking the user to install the app by walking them through the web clip process. I’m assuming the same process would need to happen for offline use of apps installed in the dashboard? So far I haven’t seen how the AppCache handling would be triggered by the manifest install, though maybe that’s just my ignorance of the AppCache. If there is some magic that happens there it would be great to see in the demo. An offline friendly dashboard and example app or two would go a long way to exemplifying the utility of the system from the mobile end at least.

I’m struggling to understand what’s going on in the AppClient code, there’s stuff going on in there I’m just not familiar with yet. I think it’s cross-document messaging, but I need to do some more studying before I’m sure. The distinction between authorization URL and the web app URL is kinda bugging me. It means I’m not necessarily buying an app when I perform a paid download, I’m licensing right to an app from a particular store. Not exactly the model I think we want to end up with. But then again, we don’t really have an alternative to compare it to that works in a distributed fashion like this.

So, awesome start, looking forward to seeing this evolve. Now I definitely need to step up updating myself on web tech, horribly behind.

In my opinion there are two major factors from the mobile web side that are pulling “web apps” into the broader discussion of applications. The first is offline web applications, which provides a way to specify a set of files that should be downloaded and cached locally so that the browser can continue to serve up the application even if the underlying system is offline. Besides the obvious benefit of being able to operate when the system is disconnected this also commonly means that the web application is given some kind of “desktop presence”. On iPhone I’m seeing more apps that lead the user through the process when they first connect to the app that results in an offline app with an icon in the launcher. This was one of the issues that most expected was hindering the mobile web, getting users to return to your app even if they liked it. I haven’t seen the same thing in practice as often on Android devices, but the common frameworks seem to be working on abstracting out this pattern across device types. I expect to see it a lot more. Having a manifest file that lists all the necessary resources also explicitly draws boundaries around your application. Sure, it’s still a web app built on HTML/CSS/JS, but it’s also in a very real sense also “shipped software”.

The other big factor is the single page web application pattern that seems to be gaining popularity. The entry point into the application is a static chunk of resources which dynamically loads the info necessary to present the app. It’s a shift from the content of the pages being the primary organizing principle the the functionality of the app being first and foremost. Organizing in this fashion actually complements the offline functionality quite well. However it presents a few issues too. It requires a few acrobatics to make sure the application functions in the absence of some of the functionality, and to ensure that users can bookmark pages sensibly and search engines have some kind of content to grab onto. I’m also not exactly sure yet how something like rearranging content around a simple layout and progressively enhancing would lie together with the single page app ideas. Seems like they would complement well, but we’re raising the bar pretty high at this point for web devs.

No matter how you slice it though, it’s pretty obvious to me at least that the conversation around applications isn’t just restricted to native dev. It isn’t even restricted to mobile. The granularity and structure of the resources being served up by all the web servers out there is starting to shift. Folks responsible for finding relevant info from the mass of data have started to pay attention to “the appiffication of the web” both on the desktop and mobile sides. I think right now we have a grab bag of techniques and some relatively new technologies that allow some of the bleeding edge folks to put together some really compelling apps on the mobile web. But I have no doubt that in short time all this stuff will be wrapped up and properly abstracted so that writing functional, fast, delightful web applications for mobile devices will be within the reach of most developers. And for the most part we’ll forget that we even passed through another era of native apps on the way to the mobile web.

• sudo apt-get install qpdf
• qpdf --password=******** --decrypt lame_pass_version.pdf happy_version.pdf

Yay! No more crashing iBooks trying to read stuff I paid money for. And there’s an actual preview of the cover on the bookshelf now. Amazing.

Definitely recommend doing the upgrade and switching around themes. Especially for viewing on iPhone/Android devices. The Mystique theme is what I’m currently using by the way. On the settings page it has a toggle for fixed/fluid layout. Ahh, nice and simple.

$this->db->save_queries = false;

sudo dscl . -create /Users/zend UniqueID 103

Which creates a zend user.. somewhere.. I’m not familiar with that bit of OS X magic yet. It’s not in /etc/passwd, but if you ‘ls -l /usr/local/zend/mysql’ you should see the data directory owned by zend again. Now just restart and you should be peachy:

sudo /usr/local/zend/bin/zendctl.sh restart

Works for Tony and I at least, so we figured we would share. голова болит секс голова болит секс