Although you are probably familiar with many components on Meshy Space, their support by a single infrastructure does not exist yet.

Be aware that Meshy Space is on a higher level of abstraction than ftp or cloud: it will use various existing protocols to transport the data between collections. At the same time, it takes over some tasks from those lower level protocols.

Disclaimer: I do not know everything. Correct me when you think I am wrong.

Comparison to other data movers

For brevety, the term fact is used for a sequence of bytes with its related meta-data; like a file with its attributes.

FTP-server Object Storage NFS, DB, or
local disk
SOAP/ Micro-
Meshy Space
Small facts inefficient
use zip/tar
inefficient fast inefficient auto-packaged
Bulk facts inefficient inefficient fast inefficient stream-lined
Authentication space single instance single instance local network single instance full network
Removal notifications no no no no yes
Built-in redundancy (mirrors) yes no possible yes
Local caching no no yes no yes
Life-time management: release, deprecate, expire no no no no yes
Democratic name- and rights rules no no no no yes
Sub- and super-setting data-sets no no no no yes
Data-structure evolution no no no no! yes

Above table should make it very clear that Meshy Space is on a totally different level of data-management as commonly used data sharing infrastructure.

Disclaimer: of course, some of the "no"s are actually "possible in some way". However, those are usually client-side work-arounds, not server-side supported features.

Comparison to data managers

Meshy Space takes data management to new levels, without understanding of what the data is. Most applications do manage complex facts and have complex configuration. The more evolved an application gets, the more it will support some kind of permission and storage management.

Meshy Space introduces Collections with Units. Any unit is a fact: some bytes to be interpreted as file or data with related meta-data. The Collections are logical groups of facts, like a directory or object. These collections implement a super-set of all features which applications need.

Some examples of possible implementations:

  • a "wallet", which collects public and private user identities in separate units;
  • a collection with VirtualHosts, each as a separate unit, as part of the configuration for a web-service;
  • family holiday pictures, organized as collection of collections, one per event;
  • Linux software distribution, as collection of packages;
  • software module archives, like CPAN for the Perl programming language;
  • publications, like news, email blacklists, security advisories, documentation, or logs;
  • definitions of interfaces, each available operation as a separate unit;
  • Web-crawler results to be shared; ...

Which collections of data do you maintain in a directory, or distribute in a zip-file. Could it be managed better?

mark@overmeer.net      Web-pages generated on 2023-12-19