Subject: Atom, files and directories: what it's all about

From: Henry Story <[email-masked]>
Date: Wed, 23 Nov 2005 12:22:38 +0100

I suppose I am kind of slow in some ways. Perhaps everyone has  
realized this all along. But the relation between atom and a file  
system has just struck me forcefully recently.

REST does not have the notion of a directory hierarchy. You may think  
it does because urls have slashes in them, and because you can browse  
the file system in a web browser. But really you are just lucky that  
most people use hierarchical file systems to construct their urls.  
The pages you get back if you point your browser to something like  
http://bblfish.net/bloged/ is an html human readable representation  
of the contents of a directory.

What is a feed? It is a machine readable representation of the  
RESTful equivalent of a directory.

What is an entry? It is the machine readable representation of the  
RESTful equivalent of a file.

Directories contain files. Feeds contain entries. Files contain  
'content'. Entries contain content too. When you type 'ls -ali' in a  
directory

bash-2.03$ ls -ali
total 61
2705932 drwxr-xr-x   3 hjs  vuser    512 Nov 22 16:10 ./
2662433 drwxr-xr-x  34 hjs  vuser   1024 Nov 22 16:10 ../
2705933 -rw-r--r--   1 hjs  vuser   2059 Nov 22 16:10 BlogEd.jnlp
2705934 -rw-r--r--   1 hjs  vuser  49674 Nov 22 16:10 BlogEd.tiff
2705935 drwxr-xr-x   2 hjs  vuser   1024 Nov 22 16:10 lib/

you get all kinds of metadata about the directory '.', and about the  
files in the directory. The first number is the inode, which is a  
little like the  src url of the content.

Same when you look at a basic feed

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

   <title>Example Feed</title>
   <link href="http://example.org/"/>
   <updated>2003-12-13T18:30:02Z</updated>
   <author>
     <name>John Doe</name>
   </author>
   <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

   <entry>
     <title>Atom-Powered Robots Run Amok in France</title>
     <link href="http://example.org/2003/12/13/atom03"/>
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
     <updated>2005-11-13T18:30:02Z</updated>
     <summary>Some text.</summary>
     type="xhtml" xml:lang="en"
      xml:base="http://diveintomark.org/">
       <div xmlns="http://www.w3.org/1999/xhtml">
         <p><i>After a crash course in french cultural  
integration...</i></p>
       </div>
     </content>
   </entry>

</feed>

The information is just presented differently. The xml makes it  
easier for machines to parse the content, as it deals with all the  
problems of unicode and separation of the data. Yes you can use sed  
and grep in unix, but you always will come across weird corner cases,  
such as when a file has a blank space in it, non ascii weird  
characters, ...

Entries and Feeds are therefore both containers. In Unix we have  
known this all along: everything is a file. It is just that  
Directories are special kinds of files, that contain files  
themselves. So, as I have argued for a long time, Feeds are really  
types of Entries.

Feeds can have images (icons) associated with them. In most end user  
file systems, so can folders. The atom group is working on adding the  
ability to add icons and images to entries too, then the symmetry  
will be complete.

Entries are really containers for file metadata. As OSX is slowly  
moving to enabling file system metadata [1],

% xattr --set name John file
% xattr --set color red file

% xattr --list file
file
         color   red
          name   John

so using the link relation one can add all types of metadata on feeds  
or entries

  <entry>
     <title>Atom draft-07 snapshot</title>
     <link rel="alternate" type="text/html"
      href="http://example.org/2005/04/02/atom"/>
     <link rel="enclosure" type="audio/mpeg" length="1337"
      href="http://example.org/audio/ph34r_my_podcast.mp3"/>
     <id>tag:example.org,2003:3.2397</id>
...
   </entry>

The attribute value of the rel relation is in fact a url, as befits a  
web document text, and people can add whatever metadata they like there.

By adding a "feed" link relation one allows feeds to point to feeds,  
which is the equivalent of directories inside directories.

A few improvements of atom over directories is that our feed can  
contain not just the current version of an entry, but all previous  
versions as well, which I think I remember was a feature supported by  
the vms file system.

Of course the URI id construct and the fact that the web does not  
have partitions, allows one to keep track of the identity of a file  
over the whole web, which simple inodes just cannot do.

Henry Story

[1] http://arstechnica.com/reviews/os/macosx-10.4.ars/7

---

From: Ernest Prabhakar <[email-masked]>
Date: Mon, 28 Nov 2005 14:16:11 -0800

Hi Henry,

On Nov 23, 2005, at 3:22 AM, Henry Story wrote:
> versions as well, which I think I remember was a feature supported  
> by the vms file system.

Interesting.  It reminds me of a thought I had a while ago:  would it  
be possible to emulate 80% of WebDAV by using HTTP + Atom?  Would we  
also need some sort of list structure, a la XOXO?

http://microformats.org/wiki/xoxo

-- Ernie P.

---

From: Luke Arno <[email-masked]>
Date: Mon, 28 Nov 2005 18:31:18 -0500

> http://microformats.org/wiki/xoxo

Yup, but Atom Feed _is_ a list format. :-)

You should check out some of the recent introspection
discussion that went on over on Atom Pub.

- Luke

- Luke

---

From: Henry Story <[email-masked]>
Date: Tue, 29 Nov 2005 10:25:09 +0100

On 29 Nov 2005, at 00:31, Luke Arno wrote:

>> be possible to emulate 80% of WebDAV by using HTTP + Atom?

I think that is very much the idea. If you check what is going on on  
the atom protocol group you will find that they are moving in that  
direction

http://bitworking.org/projects/atom/

>> Would we

Mhh. An Atom feed is a *Set* of entries. Not a list of entries.
The entries are not ordered in any particular way in a feed. That is  
stated in the spec section 4.1.1

[[
This specification assigns no significance to the order of atom:entry  
elements within the feed.
]]

In this sense it is again like the files in a directory. You can sort  
them different ways using options to the ls command, or if you have a  
graphical browser by clicking the different columns, but there is no  
objectively better order than another.

In html one could perhaps represent them as un unordered list, which  
is perhaps what the xoxo people intend.