[shalabhc]

That ST video is great.

Yes, apps are silos - why? Making non-siloed apps is harder, and integration across these is harder still. Is it possible to design the underlying system/substrate such that siloed apps are not the structures grow easily, and integration is not something that has to be 'added on', but emerges automatically?

[Jtsummers]

Have you examined BeOS, really the BeFS portion, in the past?

It offered some of these kinds of things. A contact card could be a file system object with metadata, and you could query the file system not just for them but for all contact cards that had a phone number or AIM handle in the metadata. So if applications like your mail client and chat clients are aware of this they can use one common data store and just pull info from it in a similar manner. This breaks down the silo between applications that might use the same data and/or files.

[shalabhc]

I'm aware of extended attributes and it definitely seems like a step above the completely opaque byte arrays that are the status quo. I suppose we could call it db as a file system.

Another interesting idea is the data types in Amiga OS (http://www.mfischer.com/legacy/amosaic-paper/datatypes.html). I believe it lets applications be generic enough so that as new media formats are added, the applications automatically work with them, without rebuilding or restarting.

Lisp machines were mentioned in another thread here. They also had a better story around sharing data - you shared rich structures (rather than blobs of bytes that are encoded and decoded at every boundary) - and they would update live, etc.

In the end it seems today we're entrenched in something that's reasonable, but many good ideas could be explored more.