OSDev.org

Orthogonal persistence is fine, but what if a user wants to send a file as an email attachment, or save it to a floppy (usb keychain, CD-RW, 5" floppy) for viewing on a different system (non-orthogonal), how are you going to do that? Or conversely, how about receiving and loading one?

[...]

You can't seriously expect that everyone will be running your system, and using its magical facilities to communicate that stuff transparently..

Interoperability requires that there be a tangible piece of data in a well-defined format. Humans require it to have some human-friendly identification like, say, a name.

And if your database does all of that, it *is* a filesystem, might as well call it that. Database, filesystem, "My Documents", whatever. Pretending that it is not will just make it more awkward.

That's a mighty quick assumption there. It is, of course, possible to convert data into a file format and send it in that form. Could there not be a more obvious solution?

The database would not have to facilitate this itself either, so it is still not a filesystem. The file conversion could be at any point before transmission, really.

The abstraction of having to store data on disk may be fine, until you start to care where it is stored and how. Where is my %%%ing file?!?!

Sounds like you are complaining more about filesystems than the lack of filesystems. The whole point here is that you don't care where and how it's stored.

in other words, the data will be restricted to your computer, assuming it never crashes, the hard drive never dies, and you never change the "Nothing Fancy v.1.0" data format.

The data is not restricted to your computer; I think I explained that simply enough above. I'm not saying the computer will never crash or the hard drive will never fail. In fact, there is no more real danger than in current operating systems. Filesystems get corrupted just like anything else, and hard drives go bad regardless of the operating system. It's just a matter of protection and recovery, both of which can be facilitated by some solid mechanisms in the OS or a good backup of the hard drive. I see no major problems, just a little bit of required thinking to increase the recoverability of the system. And the "Nothing Fancy v1.0" format really is "Nothing Fancy"; it's not like a filesystem or file format. Basically, this format would consist of the boot code being in the correct location and some data in the right location to specify where the page tables are. All the rest can be derived recursively from there. This "format" would basically be unchanging.

The Law of Leaky Abstractions applies to everything. Nothing about this idea is really any more leaky than the abstractions of today. It's just different.

Anyway, how about if we stick to the question instead of attempting to make it moot?

(never mind)

Anyway, what's left of the question? I think it was quite thoroughly answered before..

If you can't find any suitable resource to be fopen()ed, you can just return failure, very simple. You can either do the same for all FILE-related functions, or supply FILE*s in a system-specific way, and make programs portable to it by #ifdef'ing it or somesuch.

Sorry if I seemed a bit short with you at the end of that last post there, but thanks for rebounding like that after. Most people wouldn't do that.

Failure.... I guess that really is my only option if I really want to support the standard library. At least it seems like it would be easy to code.

Hi,

geezusfreeek wrote:A database process would simply store the data inside its own address space and communicate with the other processes in the system for the data they want.

How will a normal application (e.g. a text editor, html viewer, media player, etc) find the data it needs?

More specificially, how does the database process keep track of the data that is stored within it's address space?

One solution would be to give each piece of data a name, for example "my-little-text-document" or "a-video-of-my-pet". Another way would be to give each piece of data an identifier, for example "0000123" or "k2139dffhj".

In either case, the database process could have a special "legacy" interface, that is used by standard software. For example:

• DIR * opendir (const char *search_query) - return a list of identifiers for any data that matches the search. For e.g. "openDir("type: text_documents, length: over_1024_bytes, length: less_than_1_MB, modified: in_last_week") might return a list of identifiers for text documents that are between 1 KB and 1 MB and where modied in the last week.
  FILE * fopen (const char *identifier, const char *opentype) - open the piece of data associated with the identifier.

Cheers,

Brendan

Hmm... I do like the idea of making it fit by having directories represent queries. It sounds a bit like a better version of OS X's "smart folders." Anyway, I suppose this could work for instances where the identifier of the "file" is known, which I guess is as good as it is going to get. This thread has helped me to think about a few things.

Thanks guys.