techno.blog("Dion")

As soon as I started to play with Aptana Jaxer, I saw an interesting opportunity to port the Google Gears Database API (note the Gears in the logo!)

If I could use the same API for both client and server side database access, then I can be enabled to do things like:

• Use one API, and have the system do a sync from local to remote databases
• If the user has JavaScript, use a local database, else do the work remotely
• Share higher level database libraries and ORMs such as Gears DBLib for use on server side data too

I quickly built a prototype to see if this would all work.

The Jaxer shim of the Gears API was born, and to test it out I took the database example from Gears itself and made it work.

To do so, I only had to make a few changes:

Run code on the server

I changed the main library to run on the server via:

<script type="text/javascript" src="gears_init.js" runat="server"></script>

I wrapped database access in proxy objects, such as:

function addPhrase(phrase, currTime) {
  getDB().execute('insert into Demo values (?, ?)', [phrase, currTime]);
}
addPhrase.proxy = true;

This now allows me to run the addPhrase code from the browser, and it will be proxied up to the server to actually execute that INSERT statement.

This forced me to separate the server side code from the client side code, which is a better practice anyway, but it does make you think about what goes where. In a pure Gears solution I can put everything in one place since it all runs on the client.

Create the new gears_init.js

A new gears_init.js acts as the shim itself. Instead of doing the typical Gears logic, it implements the Gears database contract. This wasn’t that tough, although there are differences between the Gears way, and the Jaxer.DB way. The main difference is to do with the ResultSet implementation, where Gears goes for a rs.next()/rs.field(1) type model versus the Jaxer.DB rs.rows[x] model.

I actually much prefer Gears DBLib as it hides all of that, and just gives the programmer what he wants… the rows to work on.

oncallback magic

In the current Jaxer beta, I ran into an issue where I wanted the Gears library to just “be there” for any proxy requests.

You have to think about the lifecycle of a Jaxer application, and the documentation tells you what you need to know to work around the issue.

In this case, I wrapped the code in:

function oncallback() {
  // create the wrapper here
}

This is less than idea, and Aptana is playing with nice scoping which would enable you to just say “hey, load this library once and keep it around for the lifetime of the server | application | session | page”. That will be very nice indeed.

You can do a little bit of this by opening up your jaxer_prefs file and adding the resource for your file:

// This option sets up an html document that will be loaded
// everytime a callback is processed.  This has to be a local file.
// If not specified, an empty document will be loaded.
// pref("Jaxer.dev.LoadDocForCallback", "resource:///framework/callback.html");

Future…

This is just the beginning. As I mentioned at the beginning, I am interested to see where you can take this to handle clients who do not support JavaScript, and also to deal with synchronization with minimal code (sync from local to remote with exactly the same SQL API).

I was chatting with someone about how, in 2008, you could build an application with GWT on the client side, and Rhino on Rails on the server side, and how that would mean flipping the roles of Java and JavaScript. Of course, this would be a flip BACK to the past:

Netscape LiveWire enables developers to create, modify, and maintain online sites and applications through a simple drag-and-drop, point-and-click environment. The environment uses the Java programming language and a Java-based scripting language to enable developers to create and execute Live Objects, or interactive multimedia content, within their applications.

I have been a long time follower of Steve Yegge and his long blog entries that manage to keep your attention. He has the opposite style to me (I know how curt and bad my writing style is!), so I envy it a little.

Ever since he presented on the ‘Google Rails Clone’ at FooCamp and posted about the internal Google Rhino on Rails project, people have been curious to learn more.

• What does it mean to port Rails to JavaScript?
• What can’t you do since JavaScript doesn’t have the same meta programming facilities?
• Rails = a group of Active*, so did you re-implement everything?
• What do you gain out of having JavaScript all the way down?
• Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
• What is the state of Rhino?
• Will Rhino support JavaScript 2?
• How does the JVM help you out?
• What are the ramifications of implementing ActiveRecord with Hibernate
• Fun other languages to play with

And of course, the big questions:

When do I get to see it!

I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.

This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.

Anyway, give it a watch and let me know what you think:

Michael Mahemoff has been playing with server side JavaScript too.

I too haven’t heard of half of the list of Server Side JavaScript frameworks on Wikipedia, although it is certainly interesting to remember that Netscape did JavaScript on the server waaaay back in time.

At the same time, Aptana is trying to define an “Ajax server” with todays release of Jaxer. At first glimpse you can see some of the other frameworks, but it certainly is doing a lot more.

Michael hits on one of the key points when he talks about deployment:

Try finding a virtual host that supports Javascript! You would practically need one that support Java, so you can run Rhino or whatever, and few virtual hosts do that. At least Python and Ruby were running on many virtual hosts before Django and Rails showed up. For that reason, the model pursued by AppJet seems worthy. If they can come up with a solid virtualisation environment for Javascript, they may be on to a big winner.

I want to be able to hit “DEPLOY” or “PUBLISH” and have that be the only way I interact with production applications from now on (with the ability to roll back and scale out). When someone nails that, we will see a lot of applications coming out.

Maybe TheServerSide.com should become “Your JavaScript Community”?

Cedric is talking about the killer app phenomenon as it related to programming language. Of course, the term killer app doesn’t quite fit so well with languages, but the abstract concept is “reason it hit a tipping point”.

For Java it wasn’t the Applet as Cedric pointed out. I think it is a mix of:

• No more memory management (language feature)
• C like (not a huge leap)
• JVM worked OK on the server side (although a bit crap at first, ended up becoming top notch)

For PHP though, I think it is much clearer:

• Deployment. PHP was built for the Web. Remember how painful Perl was back then? PHP fit the jump from CGI to “oh, to do rich dynamic stuff we can’t fork() every time”. PHP was easy to setup with Apache, it just worked, and soon it was deployed on all hosting providers. This is why it is still a winner for so many people
• Simple, scripting based: easy to go from Perl to PHP. Easy enough for the people who liked the deployment issue to hack away (e.g. the non CSci folk)

And JavaScript? The killer app was Netscape, and the fact that it was like PHP in that people could hack away.

One of the comments on the Notification API was by lunatix:

It would be really useful if we could set a background javascript process (via WorkerPool) that continue to run after browser is closed and which is able to send System Tray notification.

I would definitely like to see an API (or as part of the Notification API, or WorkerPool in general) that allows you to attach some work to a process that can always be running, or be scheduled to run (a la cron).

This can be particularly important with Offline and syncing that comes along with it. Imagine a world where Gmail worked offline. The need for a service that downloads email in the background may not be that important, as people tend to leave a tab with Gmail running in it.

But, if you take Zoho Writer as another example. You may not have Writer open all the time. You open it when you get a new document that you want to work with. Let’s take a look at a scenario:

• Bob edits a shared document that discusses the travel for the next quarter
• Bob closes the document and keeps working for the rest of the day
• Meanwhile, Harry, Linda, and Chou all edit the document
• Bob goes offline and heads to the airport
• Bob opens up the document on the plane

Does Bob just have the document with content from his step? If there was a service that was running in the background, it could detect the changes and bring them down. Then Bob would have the latest and greatest up to when he turned off his computer.

The obvious issues

Of course, a key issue here will be making sure that this isn’t abused, and what UI do we give users. I personally never like it when I find services running on my machine when I closed an app. You know the culprits…. Quicktime and the like. I want to be able to know about every service and prune the list, but also not be burdensome for the average Joe. Does this mean that the system tray notification system has a way to see all of the services?

Also, I don’t want some rogue daemon taking up my resources, and of course, it can’t have special access to things such as key logging ;)

You can write Gears too!

A few people have emailed me about potential Gears saying that they wish they could build a new Gear. Remember, Gears is a true open source project, so you CAN write your own Gears. If you want to implement a new API, start out by emailing the group with your proposal and then get to it!

Other Future APIs

• Notification API
• Crypto API
• Developer Tools
• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

The browser is a fantastic platform to develop applications on. The reach of the Web is unprecedented and the psychology of “installing an app” versus “going to a web page” is huge.

There are still desktop integration features such as desktop shortcuts that link the browser to the underlying host in a nicer way.

One of the missing links is between the browser and the system tray and notification system.

I want to see a Notification API Gear that allows you to tie this together.

Use Cases

Instead of having to install notification agents for applications that you use such as Gmail and Google Calendar, the notification can be built into the applications themselves. You upload a video to YouTube, and it will get back to you when it is done. You choose to “watch” a particular post on the Web? It tells you when there are updates. Google alerts on certain tags do the same.

I find that in my river there are a few occasions where I want to be interrupted (which notifications can do). Depending on your preferences these occasions may be “when my wife emails” or “when someone talks about some cool Ajax thing” or “when someone emails me directly” or “when someone @twitters me”. If I really want to know, I want a notification. If it is slightly less important, I want an email.

In fact, if it is TRULY important, I may even want a text message. This is where configurability comes in. Growl is an event notification for Mac OS X, and it nails all of this. It abstracts the applications from the user. I can go in and change the dials so I get notifications when I want them, how I want them (e.g. in my face, SMS, email), and what they look like (styling). This also includes being able to turn them off.

I want Growl for the Web. Applications can get permission to add events to a notification queue, and I the user can choose how to deal with those notifications.

The API

The API itself should be as simple as possible. This is pretty much a messaging pub/sub system, where the application can publish messages on a queue for its app, with different message types for the type of events.

var notifier = google.gears.factory.create('beta.notifier', '1.0');
 
notifier.notify({
       application: "My App",
       title: 'warning',
       description: 'some text',
       priority: 2,
       sticky: 'True',
       password: 'Really Secure',
});

Growl allows you to have actions in the message itself. That would mean allowing anchor links in the description in the Web world.

There is also the thought that you could also subscribe to various events from other applications, but that can get messy.

System Tray

This notification system could tie into the system tray, or that could be its own API. I worry about the proliferation of tray icons though :)

Beware

The big worry is that people will start spamming the notification system. This is a real concern, and needs to be seriously considered from the beginning. The balance will be in how much we ask users to do, without asking too much so no notifications ever get turned on. With a growl like system it will be easy to turn on and off notifications per application.

What do you think? Is this a useful API?

Other Future APIs

• Crypto API
• Developer Tools
• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

The Google Ajax API team has given us some new magic to sprinkle on our sites. This time we have a PartnerBar, which is “a control designed to enable contextual cross linking and promotion of sites within or across network. You configure the control with an array of Partner objects which include a feed url, partner name, etc. and the PartnerBar takes care of the rest.”

Here is an example:

It is very simple indeed to setup. The bulk of my bar is in the JavaScript:

google.setOnLoadCallback(function() {
var partners = [
        {
          feed: "http://ajaxian.com/index.xml",
          moreTitle: "More Ajaxian news",
          link: "http://ajaxian.com/",
          logo: "logo-aj.png",
          classSuffix: "extra"
        },
        {
          feed: "http://devphone.com/index.xml",
          moreTitle: "More devphone news",
          link: "http://devphone.com/",
          logo: "logo-dp.png",
          classSuffix: "extra"
        },
        {
          feed: "http://google-code-updates.blogspot.com/atom.xml",
          moreTitle: "More Google Code",
          link: "http://code.google.com/",
          logo: "logo-gc.png",
          classSuffix: "extra"
        }
      ];
 
      var options = {
        linkTarget: google.feeds.LINK_TARGET_BLANK,
        numEntries: 3
      }
 
      new PartnerBar("partnerbar", partners, options);
});

There are many options for you to tweak your bar. You can use CSS to entirely change the look, and you can even do really smart things, such as grab the image for the particular section dynamically. You do this by configuring a resolver callback, such as this one that grabs the image from the RSS feed itself:

// tie the option to the resolver: { logoResolver : logoResolverCallback, ... }
 
function logoResolverCallback(partner) {
  var url = "";
  var n = partner.result.xmlDocument.getElementsByTagName("rss")[0];
  if (n) {
    n = n.getElementsByTagName("channel")[0];
    if (n) {
      n = n.getElementsByTagName("image")[0];
      url = n.getElementsByTagName("url")[0].firstChild.nodeValue;
    }
  }
  return url;
}

You can also see this running on Entertainment Weekly’s online presence. It is nice to see that this came out of Mark and his team working with EW.

I just posted about the Sun announcement on Java Applets 2.0 (even if the PR folk kept telling us it was an “update” not an “announcement”).

The web community tends to poo poo the applet. We scoff at the startup time. We complain at the cross browser issues that went against the point. We moan at the speed. We groan at the image mouseover examples.

However, if we get off of our high horse for a minute and think about what a world where Java in the browser was actually decent, we get an interesting picture.

If the plugin could be in control of the cross browser / platform issues, then it could allow us to write rich components that work on all. We could build and register a really nice file upload component for example that takes over type=”file” to do a lot more. We could use JNLP (or something else) to register the modules, and when we get winners, could even standardize them.

If we then think about SQLite databases in the browser. We could actually use Hibernate to work with it. The JavaScript / Java bridge is already decent, and could get even easier / better.

If the Java Plugin is done well, it could become a platform to build on. This is a big if though, and there is the spectre of Java 1.x in IE looming out there. Is there a way to get around that though?


// beginning of the plugin simply does
if ie and freaking old Java 1.x
run the installer
end


As I think about this, Gears and Java could actually do some interesting work together.

Man I love Greasemonkey. I am a heavy user of Google Code, and there are a few links that I wish were on the site for my use cases. I could bug the team to get these links added, but to begin with, I wanted to add them for myself to see if I really needed them.

I have changed two pages, first the home page:

All I did here was add a link to my open source projects page. Before hand, I would have clicked on Project Hosting and futzed around, or just remembered to type /u/ and gone via history. Now I have a big bold link on the top right thanks to the simple userscript.

Secondly, I have changed the project pages to add:

• A tab to go directly to the trunk of the Subversion repository for the project. This saves 3 normal clicks
• A link back to my projects on the top right, for jumping between projects. Ideally, I would change this to have a drop down of the projects.

This simple userscript does the deed.