I wanted to put my collection of pictures from Brazil online, and I wanted to do it in a way that looked good, but I didn't have a lot of time to invest in this project. A few interesting web development technologies came together to make it possible to build BrazilPictures.net in a very short period of time.
The main reason this project was viable was that Google does such a good job of opening up their web services. Using the Picasa Web Albums Data API offered several important benefits, as I describe below. Also contributing for a rapid development of the web site, which took around 40 hours over a period of a couple of weeks, were Ajax, DOM, DHTML, and a little bit of ASP.
This is the basic architecture of the BrazilPictures.net web site:
The multi-step path from my digital media on my home computer to the public BrazilPictures.net home page is made easy by the having a different piece of Picasa helping out on each of those steps.
Unlike Flickr and other similar sites, Picasa is not just a web site; it is also an excellent photo organization and editing desktop application. I didn't have to write any administrator-level functionality to organize the photos. The tools are already there that let me upload or remove pictures, add or edit keywords and captions, etc. Even the thumbnail images are created automatically for me.
From a file hosting point of view, it's good to be able to rely on Google's storage space and bandwidth. The bandwidth cost of a traditional picture web site, if it gets a reasonable number of visits, quickly gets expensive. It's amazing how much Google offers for free: storage space, bandwidth, web site, desktop application, XML API... (Furthermore, not only does Google offer the file hosting of pictures for free, but, in my experience, it does it in a way that is more reliable than the hosting company charging for the bandwidth of BrazilPictures.net.)
One last advantage of going with Picasa, compared to doing everything on my own, is that it also offers the slideshow Flash application, which is, by design, automatically integrated with the XML source.
This was my first time working with the XMLHttpRequest object. I have appreciated its advantages for years but I hadn't had the opportunity to use it in a project before.
A brief way of explaining why the XMLHttpRequest object is so beneficial to the architecture of a web site is that it means the end of scripting of client behavior on the server. Client behavior, even if it depends on remote data, should be scripted for the client agent, not the for the web server. That, in my opinion, is what has been wrong from the beggining with languages such as ASP, ASP.NET, PHP, etc.
There are a couple things that are not perfect with XMLHttpRequest, but they are minor. The cross-domain limitation, intended for improving security, complicates things slightly. Implementation varies from browser to browser, but the differences can be hidden easily. And, compared to XSLT or SAX, DOM access to the XML document is a bit cumbersome and causes some code bloat, but it still gets the job done.
I used ASP to write a very simple XML data source proxy. When the ASP page gets a request it simply repeats the request to the Google API. When it gets the response from Google, it simply makes it its own response.
I also used ASP to create a basic page template and share common HTML (the header of the page) between the few pages in this site.
I live in the United States, but I have family and friends in Brazil, and I visit the country almost every year. These are photos from from my trips. I haven't done any photography assignments or anything; these are just vacation pics.
Check also the 360-degree panoramas on my personal web site.