Michael Eakes

I've been working really hard building our new Mojo feature at Rojo. Adding Mojo to stories in Rojo is a convenient way to show the world news that you like.

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.

Kevin took a photo of us having a Rojo team lunch and blogged it from the restaurant with is Treo. When the story popped up in my Rojo reader after lunch, Kevin recursively mofoblogged that too. So I thought I'd better add another level to the recursion stack and blog him doing that:

My friend Brad Neuberg has put out an alpha version of his Paper Airplane project. Talk about a cool project, Paper Airplane lets you create collaborative wiki sites with arbitrary top level domain names through a P2P DNS, and then serve them up through NATs and firewalls. Nice work Brad.

Foglog 0.1.1 is released!

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.

Rojo is hosting a lunch:

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.

As I re-posted Robert Scoble's geek dinner attendance list, I noticed that he included XFN notation in the links. When I re-posted the links, I made sure to edit all of the rel attributes to reflect my own relationships. But I could imagine that someone who uses a tool to copy links or simply is not yet aware of XFN might copy and paste them without realizing that s/he was specifying accidental semantic web relationships.

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.

Brad Neuberg recently spotted a programmer in a coffee shop hacking on a DHTML application. There have been quite a few DHTML sightings lately, making me believe that DHTML is finally coming of age.

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.

"That's great! Actual physical contact! Can you move?"

"I feel so funky."

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.

REST (REpresentational State Transfer) describes an architecture style for networked systems. It also happens to be the underlying architectural model of the Web. Roy Fielding coined the term in his PhD dissertation.

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).

Recently at a Technorati party I discovered a poster hanging on the wall for the XHTML Friends Network. I must say I was impressed how an entire specification could fit on a little poster. And, since I have been excited about FOAF lately, I was eager to see what another social networking technology could bring to the table.

It turns out XFN takes a good stab at filling the relationship-type gap left by FOAF. With XFN, you can say this person is a friend, a colleague, family, etc. In fact, that is basically all XFN does, perhaps benefiting from the ease-of-uptake enjoyed by elemental technologies. FOAF, while much more robust in specifying personal profile information, has no provision for ontology (semantic relationship descriptions).

One of the creators of XFN, Tantek Çelik, was there to point out that there is already a spider/aggregator for the XFN network over at rubhub, as well as a collection of other tools to help you create and browse XFN information. And then while I enjoyed plenty of delicious curry chicken skewers, Marc Canter told me that since FOAF and XFN are both existing technologies, there will probably soon be some über technology that will be able to combine both networks.

I've gone ahead and tried out XFN here on my blog, both in the blogroll and in the entries. Here is how its done:

1. Add the attribute profile="http://gmpg.org/xfn/11" to the the <head> element of the page to identify it to robots as part of the XFN network.
2. Put XFN information in rel attributes of <a href> links that refer to actual people.

And for good karma, you could also add the chiclet:

My buddy Brad Neuberg has put out a major new release of P2P Sockets to include improvements in reliability, performance, and documentation.

P2P Sockets is an open source framework that makes it much easier to create peer-to-peer applications. The basic goal of the project is to return the end-to-end principle to the internet. Users stuck behind a Network Address Translator will delight in P2P Sockets' ability to transparently traverse NAT. In addition, P2P Sockets uses a domain name space that is completely decentralized and not controlled by VeriSign or ICANN (Keep in mind this experimental domain name space is not secure and still relies upon "nice" clients to avoid collisions).

Are you eager to serve into a peer-to-peer network? It even comes with versions of a webserver (Jetty) and a wiki (JSPWiki) that have been hacked to run on the P2P network. See Brad's release post for more information.

After visibly enduring coporeal pain while trying to autodiscover the feeds produced by all of the major blogging systems, Brad Neuberg just put together this Autodiscovery Hall of Shame (or in some cases accolades).

The basic idea of autodiscovery is to provide a well-defined way for services to locate a blog's syndication feed (and other semantic resources associated with that site.)

Who really cares if a blog publishing system supports autodiscovery? Mostly, the users (and developers) of news aggregation software care. They use various newsreaders to find and subscribe to news and blog feeds. That way, it is possible to view updates from hundreds of favored sites all in one place as the stories are published. Soon, most blog readers won't be actually visiting blog sites to read them, but rather aggregating the posts in syndicated form made possible with Atom or RSS.

For example, lets suppose you want to subscribe to my blog. You might know the base URI of the blog, and you can assume that somewhere on my site, there ought to be an RSS or Atom syndication of my posts. Your news aggregator (if it can autodiscover) can look in the metadata of any page on my site and find an HTML <link> tag that tells it exactly where my Atom feed is.

So, what happens if your blogging software doesn't support autodiscovery? In that case, anyone who wants to subscribe to your feed will need to come up with the full URL for the appropriate syndication file. You could let them hunt or guess, but why leave technical hurdles between your message and your audience? If your blogging software doesn't support autodiscovery of your feed (or worse yet, doesn't create a feed at all) you will be missing out on all the readers who wanted to subscribe to your blog but couldn't do so easily.

Hope is not lost for those who are using something listed in the hall of shame. If your blogging software didn't set up autodiscovery in your feed for you, just do it yourself. First, find out the full URL of your atom or RSS feed. For my blog, it is: http://www.eakes.org/blog/atom.xml

Then all you need to do is add a line like this in the <head> section of your blogs template:

<link rel="alternate"
     type="application/atom+xml"
     title="Atom"
     href="http://www.eakes.org/blog/atom.xml" />

After that, most readers can subscribe to your feed simply by providing the base URI for the blog, e.g.: www.eakes.org/blog/

The doll house pleasures of modeling one's own social network were just enough to get me to set one up back when friendster was catching on. After that, I simply can't be asked to set up the same doll house again with 18 different social network providers.

But now there is a new motivation to do it at least one more time. Tribe just became the first commercial social networking provider to implement the FOAFnet specification. This minimal specification is designed to allow portability of that carefully-crafted social network information we have been repeatedly feeding into each service.

How does the portability work? Supporting FOAFnet boils down to a social network service allowing the import and export of your relationships with other users as FOAF files. You can take your FOAF file to or from any other FOAFnet enabled service. By extracting your relationship information from a proprietary system, FOAF empowers users to manage their own social relationships.

Its still a bit of a chicken and egg problem, but at least now there is one chicken. You can try it in tribe. Build up a little network, then click on the export FOAF button near your picture. The XML shown is your FOAF file for tribe, which you can save with your browser. Marc Canter gives a good example with his own FOAF file.

What's the difference between FOAF and FOAFnet? FOAF in its full form is bulky, still evolving, and has not yet been been adopted commercially. FOAFnet however, is a consortium of software vendors that culled out a subset of the much larger FOAF specification. That smaller frozen specification facilitates the immediate commercial uptake of social network portability. Fiona Romeo's social network ideal is now much closer to reality.

Rojo, the project I have been intently working on for the past few months, is now released as an invite-only beta trial. You can request an invite. Chris Alden, CEO of Rojo Networks, just announced it at the Web 2.0 conference here in San Francisco.

I am excited to be part of the Rojo team working to make relevant information more accessible to the reader. In fact, Rojo is hiring--so if you've got the skills to pay the bills, make sure you contact Rojo.

I am excited to hear that Laszlo has been released under an open source license:

The Laszlo platform is free and licensed under the Common Public License, version 1.0. Commercial and non-commercial users are encouraged to use, extend and modify the Laszlo platform to suit their needs within the terms of the license.

Laszlo uses Flash as a rendering engine but does not use the Flash object model. Theoretically, some other completely free rendering engine could be used.

Before this there hasn't really been an open source, rich internet application platform. Well, except for the ol' DHTML work-horse that has been persistently trying to fill in some of the rich internet app vacuum.