Sports Illustrated at the Goodwill Games '98 ... it's all dynamically generated with Frontier using COM links back to an IIS web server.

Jason Levine describes the project:

We've been contracted by a fellow Time/Warner/Turner enterprise, TBS, to give away every photo that we shoot during the Goodwill Games. (Why? Because TBS owns the Goodwill Games, and wants to give it publicity, and how better than giving any press agency in the world free access to Sports Illustrated's pictures?) So, my job is to put together the web site that does this.

Our design is to have a single machine that sits at the "entry-point", if you will, to the workflow -- it's designated the Inserter (it inserts the images into the workflow). It has a folder into which you drop images, and Frontier takes over from there.

All of the images in the workflow use a file format that appends caption information to a normal JPEG, allowing us keep images and the relevant information relating to them together throughout the system. Each image is parsed for caption information and this information is fed into the ODB. In addition, a thumbnail, a preview, and a high-res image are all generated and stored to disk, and references to them are stored in the ODB. THEN, there's a list of remote machines that the Inserter sends all of this to as well -- for redundancy and backup, as well as because the server-end of the website is distributed across a few machines.

The caption information is sent to the remote machines using XML via RPC over HTTP -- it's INCREDIBLY elegant, and it means that the Inserter can be behind the corporate firewall if need be. The three JPEG files are all sent via FTP (using Alan German's tcpcmd).

One of the machines that receives all of this is an IIS web server. It talks to Frontier via COM -- when searches are performed, the search string is passed to a Frontier procedure, and the HTML is passed back to IIS to return to the client. Likewise when someone wants to generate a caption sheet (a preview of a single image with captioning information) or grab the highest-resolution file -- it's all dynamically generated with Frontier using COM links back to IIS.

There's a lot more going on behind the scenes -- we're using separate threads to maintain 100% reliability on the distribution of the images and data, we're setting up remote administration of the suite within Frontier, and the like -- and I can't imaging being able to do any of this as easily without Frontier around.

None of this relies on big hardware -- that depends only on how many hits I'm banking on being able to service and the like. The client tools are lacking in Frontier, but again, I like the fact that I build my OWN client tools -- I can't imagine that Dave or anyone else could have come to me a month ago with some solution that actually fit our workflow. (Instead, we'd have had to change our workflow to fit the solution, something which doesn't appeal to me.)

I hope that this sheds some light on why we see Frontier as a tool without which we couldn't have done what we want. It's elegant, it's powerful, and I can build my system within it, rather than AROUND it.