techno.blog("Dion")

Nick Johnson, of Google, has created a nice bridge service smtp2web.com: Allow App Engine apps to receive email.

This is perfect timing, as after my App Engine talk in Prague, a nice gent came up to me and asked for just this. He wanted to process email in his application and didn’t think he could.

One shortcoming of purely HTTP-based webapps such as App Engine is
that they can’t receive email. I know that some people are wanting to
create App Engine apps that do this, so I put together a service to
facilitate this. It runs as a standard SMTP server, and sends all the
email it receives via HTTP POST to a user-designated URL. It’s free to
use (but not to abuse)

To use the service, you setup an email account (say [email protected]) and a URL to point too. Of course, if you want an email on your own domain you could alias [email protected] to [email protected]).

Then, you would configure an App Engine controller to receive the email contents:

from google.appengine.ext import webapp
import email
 
class EmailHandler(webapp.RequestHandler):
  def post(self):
    sender = self.request.GET.get("from", "")
    recipient = self.request.GET.get("to", "")
    message = email.message_from_string(self.request.body)
    # Do stuff with the email message

The code for the service has also been released as open source on Google Code so you can check it out. You will find that it runs as a Twisted application:

from twisted.application import service
from twisted.application import internet
from twisted.enterprise import adbapi
 
import sys
import os
sys.path.append(os.path.dirname(__file__))
 
import smtp2web
 
application = service.Application("smtp2web Service")
 
settings = smtp2web.Settings(secret_key="<enter secret key here>",
                             state_file="state", master_host="localhost:8081")
 
smtpServerFactory = smtp2web.ESMTPFactory(settings)
smtpServerService = internet.TCPServer(2025, smtpServerFactory)
smtpServerService.setServiceParent(application)

Thanks for doing this Nick!

NOTE: Mailhook is another service (pay) that does something similar

I got to meet (and interview) the crew behind 280 Slides, the beginning of “Keynote on the Web.”

The application looks like an Apple.app for a reason. Two of the crew jumped from USC to Apple, and drank the Steve-aid of compelling user experience, the Mac-way.

Francisco built the beginnings of Objective-J at school, and then resurrected it later.

When they wanted to build rich Ajax applications, they wanted to use the toolchain they were used too, and thus they continued the work of porting Objective-C to Objective-J, and Cocoa to Cappuccino.

The podcast talks about how the runtime itself loads .j files and on the fly munges to JavaScript and runs. There isn’t a compilation step (e.g. like GWT generating JavaScript from Java).

280 Slides is the first application built on the framework, and people are talking about it. It seems like we have two differing views:

• “Why would you go to ALL of that work to build a framework that complicated instead of just building the darn application on a good Ajax framework like jQuery/Dojo/Prototype/…”
• “Wow, I can’t wait to see this open sourced so I can build Mac-like software too”

I can see the allure of Objective-J / Cappuccino for building desktop-like Web applications. It gives you a very high level abstraction over the browser. No more DOM. No more CSS layouts, which can be the bane of your existence for a complicated and dynamic layout. If done correctly, it can allow you to not keep making the same mistakes.

Do you sometimes feel like you are fixing the same bugs again and again? If you do, then maybe you aren’t at the right abstraction?

Then, think about how hard it is to get copy and paste working across objects. Cappuccino gives this to you, and certain Web applications will love this.

Francisco Tolmasky had a good response to some concerns on the Ajaxian thread:

Let me first lessen your concerns by telling you that can *still* do string = “Today” + date. That’s the beauty of Objective-J, it’s both languages, which means you get all the benefits of JS, while still getting to have real classes and so forth.

Now, completely separate from this, is that no *language* truly makes writing applications easier. Sure, little pet peeves may come up here and there, but 90% of what happens in an application deals with the frameworks you use. I’m sure all the iPhone “problems” you’re having with Objective-C are more than compensated by all the amazing power you get from things like CoreAnimation, which is precisely why we wrote Cappuccino.

JavaScript does not have any way of writing applications today in the same way mature platforms like Cocoa do. Cappuccino provides you with very high level features like copy-paste (of anything), undo and redo, document management and archiving, vector graphics and animation, etc etc. when you write an application for Mac OS X or iPhone, you can truly focus *just* on your application, not whether it will work on some obscure browser or how to get something as simple as undo working, and that’s precisely what we are trying to provide.

Again, Cappuccino is not for everyone. There is an incredibly wide spectrum of web content out there, from completely static pages, to dynamic pages, to full blown applications. We *only* serve the latter. It would not make sense to put Cappuccino on something like Amazon.com, but 280slides would have been an incredibly more difficult task for a 3 person team like ours without having all of the foundation already complete.

Of course, if the high level abstraction is your muse, then you should make sure that you stay in that land. Gone are the days of mashing up other JavaScript code.

Trying to find the right level can be tough, depends on what you are doing, and more importantly…. the mojo that feels right.

I have been hearing the same tune recently, and it escalates: “Man, if we could just not worry about IE 6.” It sounds familar. Every few years, we get another popular but lagging usage that holds us back.

Imagine if the majority of people were still using phones from 2001 too:

Oh wait, sometimes it does feel that way doesn’t it?

We shouldn’t be blaming IE 6 itself of course. When it was released it was a great browser. We can’t forget how Microsoft had a large part to play in pushing the Web back in the day, bringing us DHTML itself, and offering up features that never caught on as people saw them as proprietary (behaviours are awesome for example).

So, we can’t blame the IE 6 engineers. We can get a little frustrated with the fact that new machines still come with IE 6 installed on them, even though IE 7 is out there, and IE 8 is making us all feel like Microsoft could care again.

Frank, Microsoft needs to push the button. The last four times I have had to do tech support for family or friends (I need the “just because I work for Google doesn’t mean that I can fix your computer” t-shirt) they were running IE 6. I couldn’t believe it. Some of these were fairly savvy folks too.

Say we get Microsoft, and IT folk, to push the button and push out IE 7 to the masses, we will still be short on a large part of the users. Namely, the folks across the world that are running Windows illegally. Will this ever end?

Maybe it is time for large sites to start a trend. On the first Monday of the month, when user comes to your site for the first time with a browser that isn’t Grade A you show them some kind of notice that “If you like this site running Browser X, you would like it so much more if you download any of these browsers”.

This isn’t about IE 6. This is about all browsers that are low on the pack. IE 6 happens to be the one that is talked about the most as it has the huge market share as well as being painful. This also isn’t about picking one browser. We aren’t saying “Download Firefox!” We are talking about downloading ANY grade A browser. Firefox, WebKit, or even IE 7!!!!

I never liked seeing the “Better viewed in IE/FF” images, but I think this is different. At some point we need to rev our platform. It is like the cars on the road. It isn’t enough to just improve fuel efficiencies in cars. We then need to get people to get rid of their gas guzzlers and buy the responsible one!

I witnessed yet another “dynamic vs. static” argument between a couple of developers today. The age old debate just keeps on going.

I totally understood both sides. I have been in both positions. If you look at the Rails code for example, it takes you quite awhile to grok what they are doing with tons of meta class stuff. It can be a little frustrating to open up classes that all look like “class Foo; end” and you growl “where is the functionality!”.

On the other hand, I have worked with plenty of Java codebases that have me jumping through the IDE following the class – abstract class – interface trail where it seems that a ton of code could be shortened to 1/40 the size.

Obviously, it is easy to write bad code in any language (and I have done plenty of that!).

What makes matters worst is when you have the team with the one wizard. This is the guy that builds code that bit twiddles your bytecode so much that you get exceptions when testing that send you to weird anonymous blocks that don’t actually show you what is going on. You curse as you are in static language land with a great IDE like IntelliJ yet all of the information is gone. The worst of both worlds.

On the other hand, you want to bring good practices from other lessons learned. When I write Java now I often use closure-like semantics. However, I try to think about who the users of the code are, and how they are likely to think about things. If you always give people a clean API (again, very hard) then you can do a bit more magic under the hood (until it breaks and the developers can’t debug the darn thing).

As we move to the world of the polyglot, it will be interesting to see how developers cope thinking in various paradigms in the same codebase.

A core vision of Gears is that the same APIs are available on the desktop, and mobile versions.

That being said, there are APIs that will potentially make more sense on one platform or another. One of those that has garnered excitement on the mobile platform is the Location API.

Another is the newly proposed Camera API that “enables a script to trigger the camera viewfinder and allow a picture or video to be captured using the device’s onboard camera.”

That being said, this could still tie into a computers webcam.

Summary

The goal of this API is to allow a Web application to launch the native camera application and obtain the resulting media file.

On devices with built-in camera, all of the UI interaction is left to the corresponding native camera application, not Gears.

On devices that do not have a built-in camera (e.g. laptop or desktop computers), Gears will scan for attached Web cameras and will provide a basic viewport that allows the users to grab a picture or record a movie. If several cameras are attached, Gears will provide a way for the users to select the device they want to use.

This API is based on the “action-driven permission model” – the user is involved in the action and hence a separate permission prompt is not required.

You would use the API like this:

// Create a camera object
var camera = google.gears.factory.create("beta.camera");
 
// Capture an image.
var image = camera.captureImage(function(media) {
    uploadImage(media.content);
});
 
// Capture of a video, specifying a desired resolution and duration.
var video = camera.captureVideo(function(media) {
    uploadVideo(media.content);
}, 5000);

The full API proposal is:

interface Camera {
  // Acquisition methods
 
  // Triggers the camera viewfinder and invokes the callback after the user
  // has either captured the image or canceled the operation.
  void captureImage(CaptureCallback callback, optional CaptureOptions options);
  // Triggers the camera viewfinder and invokes the callback after the user
  // has either captured the video, canceled the operation or maxDuration milliseconds
  // have elapsed.
  void captureVideo(CaptureCallback callback, double maxDuration, optional CaptureOptions options);
 
  // Query methods
 
  Array availableImageFormats();   
  Array availableVideoFormats();   
};
 
void CaptureCallback(Media media);
 
interface CaptureOptions {
  string format;  // MIME type
  double width;   // desired image or video frame width
  double height;  // desired image or video frame height
};
 
interface Media {
  readonly string format;  // MIME type
  readonly double width;   
  readonly double height;
  readonly Blob content;   // reference to captured media
};

What do you think? What haven’t we thought about yet?

Other Future APIs

• Resumable Uploads via PUT/POST
• Open ID and OAuth
• Services / Daemon API
• 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: These APIs are being discussed by the Gears community and do not represent live products. Do you have ideas for cool Gears that make the Web better? Let us know!.

I got an email from Michael Slaby, CTO of Obama’s campaign, as I am sure a ton of people did who somehow said they are software developers.

I think that Barak’s webpage is by far the best of all candidates, and it even did well on my super Tuesday Ajax endorsements.

For a second I had the thought of packing up the family, asking Google for a six mouth sabbatical, and heading to Boston to try to make sure Obama wins the presidential election. Wouldn’t it be great to say to my grandkids “Yes Bobby, after 8 of the worst years the US has ever had I got in the trenches to make a difference. Not with a sword, but with this thing we used to call a ‘computer’.”

Really has kicked in, but it would be a real wild ride.

How about you?

From day one, this campaign has used technology to help build a movement of millions of people.

As we broaden this effort and look toward the general election, we’ll increasingly rely on online tools to empower these supporters.

You once expressed an interest in helping out on the campaign or told us you work at a technology company.

Right now, you can be part of the campaign that’s using the Internet to revolutionize presidential politics — and play a key role in the movement that will change this country.

http://my.barackobama.com/developer

I was really excited to launch the AJAX Libraries API (I know, I know, I hate typing “AJAX” too…. haven’t you seen the rotating header on Ajaxian? ;) at Google I/O this week.

The only problem with the timing was that at the same time that it was getting picked up by the trade rags, Wired, reddit, Slashdot, Ars Technica, etc…. I was busy getting prepared and working Google I/O! This made it hard to stay up on what was being said and really being there to comment etc.

All in all I was shocked at the level of response. I knew that developers would get it, but seeing tech journalists see value in something that isn’t flashy or even provide something “new” surprised me.

There have also been some really good comments, and tips such as this one showing a nice way to use the API side of the house (google.load vs. script src) and load your other libraries after.

I also like the Wordpress plugin that seamlessly mixes local development and “production”.

Steve Souders also had some good thoughts and stats.

The key though is what happens next. To get something out of the door for a version 1 release, you sometimes cut features and just get it out. We have some great libraries out there now, but I want to aggressively get more out. We are not trying to be king makers here. Ideally I would love a system where anyone can add their scripts, but this isn’t as easy as you would think. For one, how do you stop people from putting bad stuff on there (if you could upload anything, you could put god knows what there). One of the core goals is to have stable releases on the system only. We have to make sure that we have the rights to do this, which means that the libraries are open source in a way that we feel safe.

That being said, we want to do a better job at getting feedback on the libraries that you want to see up there, so I am hoping to do something about that soon.

Lastly, there is room to do so much more. Steve Souders can help us with the performance side of things and has great ideas on how a loader could really add a lot of value here (e.g. choose how to add a script to the page depending on the use case). Then we can work with the browser vendors and see if there is a way to aggressively cache these libraries even more. Gears itself could also have a cache module that could do this. We need to think hard about how a hashing algorithm could work here, and make sure that it couldn’t be hijacked. Brendan has me scared there.

So, overall I am excited to see how we can build on this first release, and help the community further. Please let me know what you would like to see.

Check out more coverage in the news and across blogs.