fluxcapacity

Let’s say you’re creating a photo uploader for your cool new website. You need this because you decided that profile photos are totally the way to go. (Hey, you think, Facebook was all about profile photos and it worked for them.) You let the user select a profile photo from their computer, and then they invariably pick an 8 megapixel monster photo. (No, not a monster photo, a monster photo.)

Now you’re kind of screwed. That big photo is going to take a long time to upload. This is going to annoy your user. And it’s not good for you, either: You’re going to pay for, easily 100 times more bandwidth than you actually needed, because the first thing you’re going to do if you’re smart is resize the photo down to an itty bitty thumbnail (You thought about this, and you decided that the ittier, the better, because you’re going to have to display hundreds, if not millions, of these photos as soon as Feld decides to do a month-long series on your cool new website.)

You wonder how Facebook solved this problem, and you discover that they have a special browser plugin thingy. Crap. You don’t know how to make a plugin thingy. And obviously your website is going to be really big on all the major platforms (Windows, Mac, Linux, DOS 6.22), so you’d need multiple. But even if you had one or more thingys, you haven’t quite achieved the household name status. (Except in your household, where your name is easily in the top ten household names.) Where were we? Oh yeah, even if you had an upload plugin thingy, nobody would trust you, and you’d be back to uploading monster images.

What now?

Fortunately, you remember reading about FJCore on a bathroom stall at the bar last night. FJCore, of course, is a JPEG codec that works in Silverlight and supports JPEG resize in the browser. Sweet, so now you can shrink the profile photo before you upload it without scaring off the user. Hell, maybe you’ll even allow multiple profile photos (there’s no chance your competition will see that one coming.) You could even squish the photos together to create one ultra profile photo strip. You feel so empowered that you decide to buy the FJCore guys a beer the next time you hit up that dive bar.

What’s the catch?

Right. There’s always a catch. Silverlight itself is a Microsoft browser plugin thingy… so your users still need to have Silverlight installed. But, like Flash, we expect it to be more or less taken for granted (For one thing, the Olympics will be webcast with Silverlight.) And we’re fans of Silverlight; It can do some cool things Flash can’t do (notably, FJCore relies on the ability to access a file before upload. This isn’t possible in Flash today.) And competition with Flash is good for driving innovation.

Why are we posting this today?

We just released the full-fledged source code to FJCore (on Google Code) today, so although we've had a working example online for a while, this is the first time you can just grab the code and build your own uploader.  Better yet, you can join our open source project and contribute an uploader for everyone to use (except your competition, they are way too dumb to find it) based on FJCore.

Fluxify is now running on Silverlight 2.0 Beta 2, and our open source project will be updated soon, too.

Developers should check out Scott Guthrie's new post.  Adaptive streaming, DeepZoom on existing data sets (Google Maps tiles?), better ink support, server push communications, cross-domain sockets, and graphical design and interaction design via Blend.

I came across the announcement that Mono 1.2.6 is finished and available.  From what I can tell, the new release essentially brings Mono up to par with the .NET 3.5 enhancements (like LINQ).  There was also a brief mention of Moonlight support.

Earlier this year there was buzz when Moonlight -- an open source implementation of Silverlight 1.0 -- had been written by the Mono team in just 21 days.  21 days?!  I'm not sure how they did that, but they must have burned the moonlight oil.  Anyway, if they could pull that off in 21 days, I wondered that amazing feats had been accomplished in the intervening six whole months.  So today, I spent a few hours installing the Moonlight Firefox plugin on Ubuntu in order to answer that question.

It turns out that installing Moonlight isn't exactly a cakewalk.  It's a lot easier than some Linux horror stories (like, say, installing obscure drivers) but the process had far too many steps.  At a high level, the steps are like this:

1. The quick part: download+compile mono & libgdiplus.
2. The longer part: add a handful of auxilliary packages and sources needed by moonlight.
3. The anticipation rises: download+compile moonlight itself.
4. The happy ending: copy the freshly compiled Firefox plugin into the Mozilla/plugins folder.

 Once finished, there are three basic steps:

1. Cross your fingers.
2. Load up Firefox and navigate to your Silverlight-enabled webpage.
3. Don't cry.  Remeber, it's an alpha beta.

Even if you did step 1, odds are, it won't be a pretty sight.  For instance, check out Fluxify on Linux:

 (Hey, at least it didn't crash.)  I tried a handful of other sites, and it was hit or miss -- usually miss.  Most were broken in one way or another, and they all crawled along on my relatively slow 1.5 GHz Pentium M laptop. 

The status of Silverlight on Linux

It's very cool that the Mono team is working hard to complete the cross-platform picture for Silverlight.  If you're developing for Silverlight 1.0, you should definitely get your hands on Moonlight right away.  A 1.0-only plugin can be built without dependencies on normal Mono, so you should be able to forego much of the pain.  Unfortunately, the 2.0 ( recently renamed from Silverlight 1.1 alpha ) support just isn't yet worth the installation effort, given that your application will most likely be broken.  However, if you're like me and just can't resist the allure of the creative title, and you enjoy being frustrated, you should definitely give it a try right away.

Great news for Silverlight adopters:  It looks like Silverlight 1.1 will have a SaveFileDialog.

"The good news is that we are planning on adding a SaveFileDialog() before the final release of Silverlight 1.1.", from Scott Guthrie's blog.

We were crossing our fingers for this feature.  See our previous post (Silverlight's niche, and its missing piece) on the subject.

With this small addition, you can write a web application that opens,  edits, and saves a file, without necessitating server intervention.  This opens up the possibility of replacing a variety of utilities with web-based counterparts which can enjoy active development.

Here are a few such applications which could make the jump to the browser (actual names concealed to protect these innocent applications):

Can you think of others?  Could you trust a web application to help with these tasks?

Have you ever opened a huge JPEG in your browser, only to watch it slowly download, filling up line-by-line? More than likely, this means the file is a so-called "baseline" mode JPEG. It's great for digital cameras, because it is relatively simple to encode a baseline JPEG, which means you can take pictures faster, but it's somewhat non-ideal for web display because of the sequential loading behavior.

There's a different JPEG mode called "progressive" which improves the situation a bit. Conceptually, it is useful (and quite accurate) to think of progressive JPEGs as first containing a "blurry" version of the image, followed by a series of refinements which sharpen the image, until you arrive at the final, crisp, version. There's a lot of added flexibility in the progressive mode. For example, you could first sharpen an important part of the image (say, the sea turtle's face) and get around to the rest of the image later. In some cases, it is also possible to maintain the same level of quality while shrinking file size, but doing so requires a sophisticated JPEG encoder. Progressive JPEGs are also more difficult to decode, because the information in each pixel is scattered across the file.

I have been spending most of my spare time (and some of my non-spare time) adding progressive JPEG support to Fluxify. I just applied the update to our server, and while there is nothing visibly noticeable, Fluxify should "just work" with progressive mode JPEGs. It also turns out that there was a bug that prevented us from sending grayscale JPEGs, which is fixed now, too.

So, now you can go learn all about JPEG on Wikipedia. The Progressive JPEG article isn't written yet. Any takers?