Data Fabric

Like an EnterpriseDataFabric? (http://en.wikipedia.org/wiki/Enterprise_Data_Fabric), but less 'enterprisey'.

By analogy from SwitchFabric?, a 'data transport layer' that can resolve, cache and distribute queries and events from disparate ApplicationProgram s, DataBase s and FileSystem s into a single live and persistent DataSpace. A possible solution to software ImpedanceMismatch, and a way of making EventDrivenProgramming less painful by making it pervasive at the system level.

Something computing needs to evolve before we all go insane from trying to get incompatible systems to talk to each other - even within our own desktops.

A similar concept to the SemanticWeb, taken into the domain of processes. ResourceDescriptionFramework (especially projects like HayStack) and RepresentationalStateTransfer are possible first steps toward a DataModel on which a DataFabric could be built. Also similarities with UnixPipes? and FlowBasedProgramming, with ServiceOrientedArchitecture's EnterpriseServiceBus, LindaLanguage's TupleSpace, BlackboardMetaphor, and PlanNineFromBellLabs. A somewhat higher-level idea than DataBusPattern.

Since a bulk of the work of interconnecting data from separate systems involves executing code (even small utility functions or scripts), a working DataFabric may need to be a ComputeFabric? as well, thus being a kind of ApplicationServer for GridComputing. But less 'enterprisey'.

This is all pretty interesting, but we'll need to solidify some of these concepts into easy-to-digest examples or user stories before further discussion. It is highly unlikely anybody not already intimately familiar with all these disparate technologies will follow all the links and investigate everything so as to participate in a discussion of the makeup of such a fabric.

And the real question is: WillItBlend?

Having read the ReactiveDemandProgramming and ActorVsAgent pages, this seems to be pretty much the same idea. It's difficult to reduce into specific examples as they haven't really been implemented yet. It's not about the intimate details of all the above-mentioned technologies - because they're all doing very complex things rather clumsily - but about a very simple essence common to them all. Something like massively parallel DeclarativeProgramming with a demand-driven pipe model. My intuition is that this paradigm will fit very nicely with a ConcatenativeLanguage.