Digg just released a prototype of their optimized data streams.  This this is pretty cool.  It uses MIME multipart HTTP responses to return a stream of responses, dispatching each one as it comes in.  Bugzilla has been using MIME multipart for a while, though only to serve a short “Bugzilla is searching for your bugs” message before returning the actual results.

I’m still digging through it but it looks like a great way to deal with large numbers of resources at pageload time.  As an example, you can batch 50 individual profile images in a single HTTP connection roundtrip to populate your frontpage, versus having to serve 50 individual images, or having to manually stitch them into a single image on the server side.

Assuming you can scale it well on the server, you could potentially multiplex a few long-running API calls on a single stream as well.  As each one is ready, you could then throw it down the pipe and deal with it on the client.

The concept is cool.  There are some limitations obviously, but it’s a fantastic way to deal with bulk data transfer.

More at ReadWriteWeb and Digg the Blog.

We’ve been trying out Google’s Eclipse plugin for the last week and it’s made a huge difference to our GWT development experience.  The plugin is designed to enhance your Java AppEngine and GWT workflow.  We’re mainly using it for GWT development, so the biggest wins for us are the GWT features, including:

• Auto-completion and error checking for JSNI.  JSNI is a powerful, yet horribly complex beast to work with.  With the plugin, it becomes almost as simple as working with Java code.
• Automatic management of GWT jar references.  This is a big help for cross-platform development, as each platform needs its own, specific jar (gwt-dev-linux, gwt-dev-mac, gwt-dev-windows, etc.).
• Automatic provisioning of run targets with appropriate runtime classpath entries.  GWT requires you to ensure all your translatable Java source directories are available on the classpath.  Each of the run targets you create is pre-populated with this information from referenced projects, saving you the step of manually managing them (or hacking them into your project’s global classpath).
• Support for running a unit test as a “GWT unit test”.  This lets you launch a GWT-enhanced unit test in either hosted or web mode.
• Right-click/run for any module in your GWT project, replacing custom .launch files previously required for each module.
• Wizards to create common GWT components: modules, entry points and GWT-enhanced HTML files.

There’s some cool support for AppEngine in the plugin as well.  You can publish a hybrid GWT/AppEngine project to Google’s servers with a couple of clicks.  This makes the development/deploy cycle trivial, allowing you to quickly iterate using the same environment as your production applications.  With this new toolset, AppEngine is an easier platform to deploy to than servers you own and operate yourself, IMHO.

Aside: one interesting feature that slipped under the radar for this AppEngine release is support for cron-style jobs.  While this was possible using a cron job on a managed server hitting a URL on your application instance, implementing it in the platform itself makes life easier for web developers.  Note that this isn’t true cron, but rather a “hit this URL on this schedule” feature.  I actually prefer having cron jobs exposed as web endpoints – it saves you from having to duplicate your web framework’s infrastructure setup in a command-line application.

All-in-all, a very cool release.  Thanks to the GWT and AppEngine teams for making this a reality.