funkatron.com

Our move to using oAuth for authentication in Spaz is going well. Many people have stepped up to help get the SpazCore libraries working, and Spaz Desktop has been updated to use the new authentication methods, both in the 0.8 branch and master.

However, Spaz webOS still hasn’t had work done on it to get oAuth working. July 16th is the Twitter Basic Auth cutoff, so we don’t have much time.

Here’s the big news: Palm has donated Palm Pre Plus phones for AT&T for me to GIVE AWAY to the top 3 contributors to Spaz webOS from now until July 12. That’s the day (I believe) we need to submit Spaz webOS to Palm for review, so it can be ready by the 16th.

So, you want a free phone? Get your ass in gear. Download the SDK now: http://bit.ly/duAHNg

To get through Palm’s review process, I believe we need to submit by July 12th. So before then, two things need to happen in Spaz webOS:

• Twitter accounts need to use oAuth to authenticate, using xAuth to exchange username/password for auth keys initially
• Image uploaders need to use oAuth Echo to post

We’ve already accomplished this in the Spaz Desktop 0.8 branch, so doing it in webOS is very doable. Whether it gets done in time is up to you. I am on Twitter, available via email, and in #spaz on irc.freenode.net regularly to answer any questions.

Palm has been a major supporter of open source, and Spaz is (AFAICT) the only open source microblogging client available on the platform. Help me keep it going, please.

Spaz has been around a long time: since early 2007, which I think makes it 77 in Internet Years. It’s been a while since I started playing with the Twitter API in RealBasic, and later under AIR after I saw the Pownce desktop client and wanted to make my app look cool like it.

A lot has happened since then. A lot of cool stuff with Spaz, and lot of cool stuff for me, and a lot of sometimes cool and sometimes not so cool stuff with Twitter. Now we have a desktop client, still on AIR, and a native mobile client for webOS. Spaz isn’t SUPAR POPULAR, and it’s not proved to be anything but a giant time and money sinkhole, but it’s been a very fun ride.

Through all of this, Spaz has stuck with open technologies: JavaScript, HTML and CSS. We’ve done so because we’re dedicated to true openness and transparency. The Spaz Statement of Purpose spells out the project’s reason for being. And in the light of Twitter’s moves to make the microblogging client scene more of a closed monoculture¹, the significance of Spaz as a counter to closed technologies is greater than ever.

After some recent events – a big career move for me, some horseshit policy changes by Apple, and some disappointing moves by Twitter – I decided we needed to assess where Spaz is headed. So, like any good open source project guy, I went to IRC: I called a meeting on Freenode in #spaz. Turnout was encouraging, and we made some important decisions.

Here’s what’s going to happen:

Most urgent: implementation of OAuth/xAuth by June 1

In June, Twitter is shutting off HTTP Basic Auth support. For client apps to function, they must start using OAuth or xAuth. Spaz Desktop has been approved to use xAuth, an OAuth variant where the user enters their username and password, and the server exchanges these for an OAuth access token. This means we can support a more typical user experience, but don’t have to store credentials anywhere — we just store the access token.

Earlier this week I added support in the SpazCore Twitter library to authenticate with an OAuth access token instead of Basic Auth. This should allow apps using SpazCore to use either Basic Auth (for systems that still support it, like StatusNet) or OAuth/xAuth. Much more needs to be done, though, to get Spaz Desktop and Mobile ready.

Short term: get Spaz Desktop 0.10 out the door in June

The Spaz 0.9 branch, which is the development branch for 0.10, has been stuck in dev for far too long. The codebase has been refactored considerably, and a number of cool features either have been implemented or are planned, but it needs to actually get ready and usable. We need a push, and assistance from a number of motivated folks who are willing to put the time in. Our 0.10 milestone entry on spaz.lighthouseapp.com outlines the various tasks that need to be completed.

Longer term:

1. Move Spaz Desktop from AIR to Titanium Desktop by October 2010

I’ve been a big fan of Appcelerator’s Titanium for a long time, and their Desktop product offers a compelling alternative to AIR for these reasons:

• Titanium is a true open platform: open source with a liberal license
• JavaScript is fully a first-class citizen in terms of language support²
• Titanium allows leveraging Ruby, Python or PHP
• Better Linux support
• Web Worker support
• Full interaction with external processes
• Native installers for each supported platform that includes the runtime

The big knock I see against Titanium is poor documentation, and that’s something I really hope Appcelerator works to rectify.

All in all, though, Titanium is a better fit for us, technology and philosophy-wise. Porting to Titanium is probably about 20 hours of work as it stands now.

2. Start development of web-based mobile/tablet client

I really like powerful mobile devices, and I really like multitouch tablet devices like the iPad. What I don’t like are the restrictions being placed on developers by companies that refuse to be transparent about their policies. I think the way around that is to make a great mobile/multitouch web app.

A web app will also make Spaz available to all devices with mobile webkit browsers. It would run on Android, Palm webOS, and likely BlackBerry and Nokia devices (I’m not super familiar with those, but I believe they have webkit browsers now or will soon).

While Spaz will be a hosted web application, it will still be FOSS, and anyone would be able to get the source and set up their own install. In this sense, it would be an interesting complement to StatusNet.

If folks are motivated to create native clients for their preferred devices, that’s definitely a possibility — either with a wrapper system like PhoneGap, or a native UI system like Titanium Mobile. It just would not be, at least initially, a primary goal.

What about webOS? Not sure right now. It requires dedicated folks who will keep up with it. Nick Carter has helped a lot, but we need more help, and/or we need to leverage the stuff we do in the web-based mobile client. That may necessitate moving away from Mojo as a framework, though. Palm’s dev relations team has indicated that they are interested in making web apps first class on their system, though, and I suspect they’ll have some interesting stuff to make that possible.

3. Target StatusNet as a top-tier service

StatusNet has always been a favorite service of mine. They match our principles, and I think Spaz as a FOSS client and StatusNet as a FOSS service complement each other well. StatusNet needs better clients, and I think Spaz is decently positioned to be a part of that. So, I think we should create a StatusNet API library to support any StatusNet-specific features available, and implement support for this in Spaz.

We should also consider other services, like Facebook and RSS feeds. The first step would be developing SpazCore libraries for these.

How to help

If you’re interested in helping with Spaz, here’s what you can do:

• Read our Statement of Purpose and Diversity Statement
• Read “How Can I Participate in the Spaz Project?”
• Talk to us about what you’re interested in doing
• Make a commitment to putting in a certain amount of time every week. Even a half-hour a week helping with user support is a big help.

You don’t have to be a programmer. We will work with you to learn new skills. All you have to be is interested in building something cool with us.

No more travels for me until SXSW in March, I believe. I’m far too tired.

Did I say that? I actually knew very well that a week later, I would be traveling to San Jose for ZendCon 09. Foolish me.

I spoke at ZendCon on Building Desktop RIAs with JavaScript and PHP. I’ve given this talk other places, but this time I showed off some fun PHP-powered jQuery within Titanium. Here’s a snippet:

<script type="text/php">        
    /**
     * run the passed function when DOM Ready event runs 
     */
    $jQuery()->ready( function () use (&$jQuery) {
        /**
         * set some CSS properties 
         */
        $jQuery('#phpjQ')->css('display', 'none')
                        ->css('background-color','#333')
                        ->css('padding','10px')
                        ->css('border','2px solid #000');
        /**
         * bind a delegated click event to the passed function 
         */
        $jQuery('#invokePHP')->live('click', function () use (&$jQuery) {
            /**
             * set the text color and reveal 
             */
            $jQuery('#phpjQ')->css('color', 'red')->slideToggle(500);
        } );                
    } );
</script>       

Building Desktop RIAs with JavaScript and PHP

• Slides
• Code: Server-side PHP, AIR, Titanium

Unlike some others, I only participated halfway in CodeWorks 09, doing the east coast leg of Atlanta, Miami, Washington, D.C., and New York City. It was an enjoyable adventure, and I liked being able to try different approaches in my talks and see what worked best.

I was able to record audio with the voice memo app on my iPhone. Getting hour-long recordings off is a bit of an adventure – they refuse to appear in the voice memo playlist in iTunes, so you have to find the files in the MobileSync backups folders and do some renaming work – but they turned out pretty well.

Introduction to CodeIgniter

• Slides
• Code
• Audio (recorded in NYC)

Building Desktop RIAs with JavaScript and PHP

• Slides
• Client Code, Server Code
• Audio (recorded in DC)

No more travels for me until SXSW in March, I believe. I’m far too tired.

In the past two years I’ve spent most of my free time working on desktop applications written in JavaScript, HTML and CSS. I write them on top of web runtime platforms like Titanium and Adobe AIR, and more recently Palm’s webOS. In this time, I’ve heard a misconception raised repeatedly: that “local” (desktop or mobile) applications written on top of web runtimes offer no advantage over remotely-hosted, browser based apps. Or, to paraphrase something I overheard recently:

HUH huh your app is written in JavaScript and HTML, why don’t you just load the web site DURRRR.

I suppose this kind of thinking comes from the JS+HTML+CSS being almost exclusively used for web site front-ends for so many years. It’s a knee-jerk reaction, much like the one that says “oh, you can’t use PHP in the ‘enterprise’” or “Oreos aren’t for breakfast.” Proved my mom wrong on that one.

So, I decided to make a list of what things you can do in a web runtime platform that you can’t do in a browser. Now some of these vary depending on the platform or the browser, and I’ll try to make note of them in my list:

1. Cross-browser compatibility issues are a thing of the past
   I should offer a caveat here — even though the rendering engines are the same, you’ll sometimes run into OS rendering differences. AIR, for example, supported CSS3 box shadows on OS X until v1.5, but never did on Windows. But the differences are far, far smaller than you’d see between, say, Safari 3 and IE6. Trust me — you will love not having to worry about getting your layout working in some ass-tastic box model implementation anymore

2. Advanced rendering features (CSS3, etc)
   Since you don’t have to worry about looking the same in different browsers, you can take advantage of the special features your runtime’s rendering engine supports. Titanium, for example, supports the same advanced CSS features that Safari 4 does, like box shadow, border radius, and CSS gradients.

3. File system access
   On desktop web runtime platforms like AIR and Titanium, you can interact with the filesystem just like any other application: read, write, and create files and folders with the permissions of the executing user. webOS offers less freedom in this respect, but you can read and write files on a limited basis.

4. Networking
   Both of the major desktop web runtime platforms provide much more advanced networking capabilities than are available within a browser. I’m not much of a networking programmer, but both platforms allow the developer to open TCP socket connections and communicate over them. Titanium seems especially well-prepared in this area, with its ability to leverage Python and its powerful networking capabilities.

5. No same-origin policy restrictions
   If you want to pull data from a web site other than your own in the browser, you have to resort to JSONP — basically an XSS attack waiting to happen — or set up a proxy on your site’s server. Web runtime app platforms don’t have this issue, so you can make XHR calls to any domain you wish, and interact with any APIs.

6. No need to support non-JS users
   This might seem like a small issue, but having to support users who have disabled JS was one of the major reasons I never did serious browser-based frontend programming before I started working on Spaz two years ago. Now the cool kids at SXSW will tell you that “nobody” disables JavaScript, but I think that’s kind of short-sighted.

   Nevertheless, this argument and the need for graceful degradation and “unobtrusive” JavaScript become moot in the web runtime app platform. JavaScript is there, it’s expected, and you can’t disable it. So go crazy.

7. Using/interacting with platform-specific UI elements
   This includes things like window chrome, menu systems, Dock items (OS X), menulings (OS X) and the System tray (Win/Linux). Both major web runtime platforms display your application within the native window chrome, allow you to create native menus, and give you some access to the system tray and OS X’s Dock. Titanium is a bit better in this regard in that it inherits the native look of form widgets and scrollbars, and provides access to the OS X menubar (those little icons in the top-right).

8. Sound playback without plugins
   Until HTML5 becomes standard in all browsers and bestows the grace of plugin-less media playback, we’re stuck <embed>ing <object>s in our gorgeously crafted markup. Funk dat. Web runtime platforms provide sound playback APIs that mean we don’t have to stick a Flash applet in our document and hope it doesn’t catch the CPU on fire. AIR has a particularly good playback API (probably because the whole thing is running in a Flash engine. Small victories).

9. Interacting with other applications/shell interaction
   Being able to leverage other applications on the machine/device can be really valuable, especially on Unix OSes (Mac OS X, Linux, etc) that have a bevy of useful utilities available from the shell. Titanium is the only desktop web runtime platform that allows the developer full access to these capabilities; AIR is limited to interacting with other Flash-based applications at this time (although this may change in the future). Runtimes on mobile devices are typically much more limited, although webOS’s Application Manager service does let applications launch and pass arguments to other apps.

10. Database support
    Typically this is implemented either via the HTML5-style database stuff (usually asynchronous) or a platform-specific SQLite (usually synchronous). Out of the box, support isn’t provided for external DB servers (MySQL, PostgreSQL, MS-SQL, etc), but with Titanium this should be possible by delegating to Python or Ruby scripts, or Titanium kernel modules. DB servers that provide HTTP interfaces (like CouchDB) will work fine, though.

All of this doesn’t mean web runtime platforms are going to replace browser-based apps anytime soon. There are clear advantages to remotely hosting an application (speed of updating comes to mind), and supporting an app on a user’s machine brings a new group of debugging headaches. But for applications already chafing at the limitations of the browser, web runtime platforms offer a compelling option.