What is a TUBE?
A tube is a text file that contains information about a collection of items, along with the list of items itself.
The main information stored includes:
UUID – A universally unique ID
Canonical Home – A URL which can be used to track the “original” version of a tube
Creation TimeStamp – UTC formatted date time
Item List Count
Each Item has the following:
File name (including path on host system)
Link to previous versions if any
Link to future versions if any
Items can contain a lot of things, but NOT their own rule sets... if you need to do this, put tubes inside of tubes. (Recursion, ain’t it fun?)
The evolution of the Tube container
Here is a typical MS-DOS list of files in a folder (in this case, the example folder)
02/27/2009 04:17 PM 400,345 2 Trees in Chicago.jpg 04/09/2010 02:56 PM 739,231 Bean02_F01_Crop.jpg 03/31/2009 10:10 PM 1,268,434 Chicago Theater.jpg 02/12/2009 01:15 PM 1,114,464 Marshall Fields Clock.jpg 07/17/2008 04:22 PM 485,158 Warot_Mike_RailroadSignals_2008.jpg
As you can see, it gives the relevant details for a set of photographs, including date and time stamp, file size in bytes and the name of the file.
Now, that alone is insufficient for our purposes because there is no path information and no URL to make it universally accessible.
A first pass at it might be something like
NAME=2 Trees in Chicago.jpg
NAME=Marshall Fields Clock.jpg
Services are the connectors which make things work
The thumbnail service would be able to create thumbnails or other scaled images of the items in the stream. The items produced by this service are derivative, and not equivalent to the original items, thus you would not want to sync them back. (But their metadata would still be synced)
The sharing service would allow others to make their own clones of the tube and sync there metadata back, based on their preferences and capabilities tokens. Replacing an image of a replica could be synced back, depending on preferences and capabilities tokens.