I’m especially excited because we’ve really “kicked it upstairs” for this feature with a new back-end architecture that we designed to make our mojo extremely snappy and scalable.

Here’s a screenshot showing this story’s mojo count in the upper-right corner. Just click it to add your mojo to any story. The first person to add mojo to each story gains a little bit of “microfame” (the link in the bottom right corner).

I am pleased to see that this kind of black box testing is out there for browser compatibility standards. This Acid2 test reminds me of the “Machine Problems” we had to do in Computer Science at the University of Illinois, where we had to match our output byte-for-byte to a reference implementation.

I created Foglog for my own photo organizing and publishing needs, and am pleased to offer it to the open source community.

Foglog is a web based photolog hosting system built on top of a web-accessible, lightweight digital image repository. Foglog achieves both hosted photo publishing and archival quality private collection management from a single repository. This eliminates the need to upload an arbitrary subset of your work (as well as low resolution copies) into a separate photo blogging tool. All the work that you invest in your photo collection (organizing, categorizing, rotating, etc.) will immediately be reflected in your published photos as well.

My example installation of Foglog can be seen at eakes.org

Foglog operates in two modes, public browsing mode and private management mode. The public sees a published photostream and can browse public photos by date, set, tags, and by individual permalink. When logged in as the owner of the photos, management features are available to browse, rotate, tag, organize sets, and publish photos. Additional admin features include viewing photos by popularity and graphical access logs by session.

The target user is an individual photographer who would like to share photos and photoblog.

Foglog is written in Python, and uses Apache, MySql, and netpbm. It currently runs on Debian.

This is an alpha-level release, but still has basic photo hosting functionality. Please give it a try and tell me what you think.

We are hosting a lunch with a select group of Rojo users at our offices in San Francisco on Wednesday, January 12th at noon. If you’d like to participate and help Rojo be the best it can be, please let us know by emailing us at feedback@rojo.com. Space is limited and participation is by RSVP only.

Those rel attributes convey one-way relationship information; from the owner of the containing page to the owner of the link. XFN tools must infer that the originator of the relationship is the owner of the page in which the link exists.

Since one half of the relationship is implied from the context of the containing document, there is a danger of misrepsenting relationship information by decontextualizing (re-posting) links that contain rel attributes. This problem would apply to any use of the XHTML rel attribute.

Maybe this won’t happen much, but I wonder if we can come up with something to help keep the XFN network from being corrupted by such decontextualization.

Dynamic HTML is not a specific technology but rather a technique of creating rich internet applications by augmenting static HTML with client-side scripting and style definitions. In practice this is often done with HTML, JavaScript, and CSS.

There are various other frameworks for rich internet applications, such as Flex and Laszlo, but they have not gained popularity; perhaps this is because they rely on Flash as a 3rd party browser extension. Since DHTML relies only on Javascript and CSS, which are now both widely supported in modern browsers, DHTML should be clear for take off.

So what is the holdup? The biggest gotcha with using DHTML is having to wade through the qaugmire of browser incompatibilities in their support for Javascript and CSS. Javascript-based DOM methods in one browser might not have the same effect in another browser. Also, the lack of cross-browser CSS support creates a large amount of developer consternation.

Some folks are working to fix the mess. The open-source x library encapsulates all the DOM incompatibilities by creating a browser-independent javascript API for DOM manipulation. On the CSS front, Dean Edwards has taken the approach of “leveling the playing field”; his cheekily-named IE7 project is a complex layer that makes Internet Explorer behave in a CSS compliant way.

These kinds of grassroots efforts are typical with DHTML, because unlike Flex and Laszlo, DHTML has no standard libraries or toolkits. In fact, the community has been re-inventing DHTML tools for years without coming up a standard cross-browser DHTML solution.

Things have come a long way, however, and the frontiers are now being pushed with DHTML. Mihai Bazon of Dynarch, for example, has produced some really slick DHTML menus and other widgets; I even found myself right-clicking on them to convince myself that they were not actually coded in Flash.

DHTML seems to work best when applied lightly and transparently, avoiding the worries of rich internet applications. Some of the best uses of DHTML are when you don’t even realize that it is DHTML, such as Google’s GMail. I believe DHTML is least effective when used in an attempt to make a web application look like a desktop application.

With all these cool new techniques, DHTML can also bring a few annoying possibilities, such as DHTML pop-up ads. Many users have been switching to security conscious browsers and otherwise blocking ads that pop up in separate os-native windows, but DHTML pop-ups are a whole new way to get your attention. The first time I visited this Time Magazine story, I was barraged with two (annoying but harmless) DHTML pop-up ads.

As more DHTML libraries and widgets are released with open-source licenses, it seems more likely that DHTML will continue to gradually enrich web applications enough so that the adoption of a separate RIA framework like Flex or Laszlo might no longer be necessary.

Rubhub, the XFN Aggregator, finally indexed my XFN Friendly blog. Last month I wrote a post XHTML Friends Network. Inside that post, I included some links with xhtml rel attributes (with values from the XFN spec) to specify my outgoing relationship to various people. After that I visited rubhub and added my site to their aggregation list. Now, rubhub has indexed some of the relationships that I included in the post and in my blogroll. For some reason though, it only picked up 3 out of the 8 distinct links I had adorned with XFN rel attributes.

The basic characteristics of a REST system are:

1. Client (browser) and server
2. Stateless Interactions
3. Cacheable Resources (using Meta info)
4. A uniform interface (HTTP)
5. Named resources (URIs)
6. Interconnected resource Representations (a href)

So, the web is already a RESTian system. The parenthetical information after each item in the above list shows how the current Web satisfies that design principle.

The idea of making a RESTian system is to see it as a data resource manipulation problem. To sum up the REST Best Practices from a presentation by Roger L. Costello:

1. Expose a URI for each resource
2. Use logical URIs (not physical)
3. Use nouns in the URIs (not verbs)
4. Use the / in URIs to represent parent/child relationship
5. Minimize use of query strings
6. use GET for resource representations (not POST)
7. Make all HTTP GET requests side-effect free
8. Include links in responses, gradually unfolding information.

Strong proponents of REST such as Mark Baker purport that it is a natural tendency for document oriented systems, because documents are in fact state.

From an article by Paul Prescod:

The best part about REST is that it frees you from waiting for standards like SOAP and WSDL to mature. You do not need them. You can do REST today, using W3C and IETF standards that range in age from 10 years (URIs) to 3 years (HTTP 1.1).