Tuesday, March 28, 2006

I have become more sadoo

Yesterday I watched "Zinda". A good movie. As usual, dutt always has some different kind of role. Though his appearances in most of the movies is same i mean a strong man who can beat some 20 people, with a knife in his back and still manage to walk out laughing. Am I telling you the complete story? Ok...the story is comlpetely different. I mean narrated in a nice manner. You will not get bored. It makes you curious, why he is kept locked for 14 years! Initially I thought, must be some NSA kind of people trying to use him for some critical mission etc. I got this thought because dutt is a software engineer in the movie. But there is one thing worth noting in the movie, never tease any girl or make fun of her. Especially if she has a brother and is very young around 8 years. Confused? Zinda, dutt, software engineer, NSAn eve teasing.......hahahahah. Dont be..go and watch Zinda. I have stopped betting too :(

A brief introduction about atom

I should have put this long time back. Now the protocol has come far away, but the basics remain the same. I am putting it here for newbies to understand what is Atom and Atom Publishing Protocol.

Atom comprises of two parts.

  1. The Atom Publishing Format.
  2. The Atom Publishing Protocol
The Atom Publishing Format is a standard(rfc 4287), which describes the format of a atom document, termed as an atom feed(mime type "application/atom+xml"). The atom feed is a xml document representing the "change" in the content. It is a list of "entries". Each entry has a title, author, publish date, content summary etc. The idea is that each entry represents some prominent change in the content. For e.g, a book shop owner might add new books to his library, in which case, information about each book can be represented as an entry. The entry content is the content that the user is interested in(about the book). The content usually is the changed content(which may not be in some cases) and the summary is a brief summary of the change, usually a single line. Each entry also has a "link" element. The link element is used to provide the client with an "alternate" or "related" URL which the user might be interested in. When the "rel" attribute is "alternate", it means that the entry also has an alternate representation for e.g html page or plain text. When the "rel" attribute is "related", it means that the link points to some other resource which is related to the entry. For e.g, an entry representing a horror book may have a related link of similar books or a different volume of the book etc.

The Atom Publishing Protocol (APP) is a protocol for editing web resources using the HTTP model. It specifies, how resources on the web may be created/edited or deleted using the HTTP verbs, GET, PUT, DELETE, POST, HEAD. Basically, the protocol is similar to HTTP, only that the data exchanged in the form of atom feed documents. The APP also defines new termiologies. Important ones are given below :

Workspace : A group of collections.
Collection : A collection is similar to a directory or a folder in the filesystem. Every collection has a type. The type can be "entry", which means that the collection SHOULD contain only atom entries, or it can be "media", in which case the collection CAN contain files, documents of any type.
Feed : A list/collection of entries.

Before any client can start interacting with the APP server, it first GETs the Introspection Document. This document defines all the workspaces available in the server along with the collections under each workspace. It also contains the type of collection, i.e entry or media. Every collection has an URI which is also mentioned in the introspection document. This URI is the key to access all the resources in the APP server. The introspection URL is publicly available, usually located on the homepage of the website. Mime for the introspection document is "application/atomserv+xml".

After the introspection document is retrieved, the client makes a GET on the collection URI. The server sends an atom feed listing all the available entries. The number of entries listed in the feed depends on the server. It may not be the complete list of all the available entries. The client can then make a GET/PUT on the entry URI to manipulate it. POSTing to the collection URI causes a new entry to be created on the server. After successful creation the server sends a representation(resource url, id etc) of the newly created entry. PUTing updates an existing entry, and DELETE causes the entry to be premanently deleted from the server. While manipulating the entries the client has to respect the type of the collection, i.e entries should be posted to collection of type "entry" and other arbitrary files should be posted to collection of type "media".

As of now, the resources are categorised as "entries" or "media", but there isn't "entry type". Entry types can be :

  1. Standalone entries - These entries are standalone, i.e the entry stands for itself. The content is all that the entry wants to say about. There is not alternate or related link.
  2. Stub entries - These entries are on behalf of some other resource. e.g a resource uploaded to the media collection has a proxy entry in the entry collection with a link to the actual resource in the media collection.
  3. Referencing entries(Ummm..or some other name?) - These entries say something about some object, but not completely. The complete information about the object is available as URL in the link element of the entry.
The atom standard does not implement entry types. The above abstraction was developed by me and my friend vinod.