I hope this is not my legacy

I’ve been thinking some more about FluidDB. I mentioned in this post that I did some work adding features to the .Net FluidDB open source project hosted here.

Currently the API has a basic layer for making raw calls to the RESTful FluidDB API, a second layer abstracting the behaviour of FluidDB into CLR objects (FluidObject, FluidTag, FluidUser etc), and a third layer allowing attributes to be used to easily specify a mapping between CLR properties and FluidDB tag values.

For example:

[FluidDBObject]
public class Person
{
/// The tag value will be a json primitive
[FluidDBTag]
public string Name {get; set;}

/// The tag value will be the GUID of the father FluidDB object
[FluidDBObject]
public Person Father {get; set;}

/// The tag value will be the serialized data with the MIME type specified
[FluidDBTagValue("image/jpeg")]
public BitmapSource {get; set;}
}

Person g;
// create a FluidDB object for my CLR object
// tags will be in the namespace guy127917/test
FluidDBGUID id = g.WriteToFluidDB(FluidDB, g, "guy127917/test");
// retrive a Person object with the specified ID in the specified namespace
Guy p = FluidDBAttributeWriter.ReadFromFluidDB
(FluidDB, "guy127917/test", id);


This is a work in progress, some of it sort of works, but don’t count on it yet (if you need it to work, help make it work!).

One of the slight issues I have with it is that if you have a class with a whole bunch of properties it can take quite a while to retrieve each value. The time taken is purely due to making a socket connection for every http call, which occurs every time you query FluidDB. Since primitive values are stored as JSON (strings, numbers, booleans), and JSON has provision for storing “objects” (collections of named values), it would seem that storing all primitive values in a single tag value as a JSON object would solve this problem- all values would be retrieved in one API call to be parsed into the appropriate CLR properties.

The drawback of this approach is that there would be a single FluidDB tag value on an object which means that the data is harder to query for a given tag value, and harder for other people to see what tags are available for them to use. Since data interoperability is the core value of FluidDB this is quite a big deal.

From the perspective of the .Net API, it could easy allow a tag name to be specified as an argument to the FluidDBTag attribute for primitive types, allowing grouping of property values into a single tag value e.g [FluidDBTag("TagGroup")]. This would allow you to decide which values ‘deserve’ their own FluidDB tags. However, what is not particularly important to your app may be the killer for someone else wanting to use the data. For example you may bundle geo-positioning values in with a load of other data because they are not crucial to your app, but someone else may want to search for objects in a given location.

I’m not going to implement this right away. For starters I don’t have an app which requires performance. Secondly I’ve heard unsubstiated rumours that some sort of batch request API may be in the pipeline. Thirdly other more important things in the .Net API need work much more urgently. And finally, I’m kind of convinced by my own interoperability argument, data should be as easy as possible for other people to be use in order to get other people to add value to your application data.