This blog is highly personal, makes no attempt at being politically correct, will occasionaly offend your sensibility, and certainly does not represent the opinions of the people I work with or for.
ωFS internet awareness
ωFS published its first web datablock last night (3.52 am) at its first storage point: (in this moment you will see a small text file and Aubrey's current wallpaper -- data is not encrypted so if you put pieces in the right order you should be able to recover the files -- note that I am not going to use that storage point anymore, keeping it as it is for historical interest). I was so happy that I instantly fell asleep, and it wasn't until I woke up that I wrote the four lines of code that would allow it to retrieve the datablock thereby recovering the virtual block. I am not using PHP to interact with Blogger, instead, relying of the very excellent Python code provided by Google. Calling Python from PHP wasn't a problem so it worked the first time I ran it.

I have updated the system diagram to reflect the improved architecture (full version here)

The Data Manager is a very nice piece of code and makes little, if any, assumptions about the protocols. Protocols just register themselves to the Protocols Manager (which in turn is given to the Data Manager) and everything is nice and easy from there. I have tried to put as little burden as possible on the design of the protocols and storage points, and the two interfaces they have to comply to are in the next picture

Any given protocol (Storage_Protocol object) does little more than distributing storage point agents to whomever needs them. A storage point agent must only know how to store and retrieve a datablock. How it does it, is up to it. When storing a data block the agent is expected to return a unique identifier that will be written in the i-node. This unique id is meant to have a meaning within the context of this protocol. In today's example that would be a weblog post id (provided by Google's API). The agent may also know how to delete a datablock. The delete_datablock function is always called when the virtual block (that the datablock belongs to) is deleted form Iris, but can be left empty if the protocol does not support deletion.