Re:Core - Content in filesystem?

posts: 49 Uruguay

I'm having random thoughts about my random thougths smile, and thinking in the structures to store my proposed hierarchical tree of information, and having also a hierarchical name system proposed for that objects, looked interesting the possibility of storing all of this in the filesystem, instead of a sql database.

Think about it... having a directory (probably outside the web tree to avoid unauthorized acccess or accessing directly to the content) where all the directories are objects, and all the files attributes of that object. Attaching objects to any object will be mostly natural, adding a new handler for new propierties will be also in that data structure, just add another file with an unique name and thats it.

A wiki page could be a directory that have the name of the wiki page (maybe wiki.PageName if you want to give the kind in the name, or a file inside called "kind" that say inside just "Wiki") where you have a file named content with the content (or textcontent to make that different with binary content kinds), but also could have directory for each attached file or graphic. History could be represented with files named content.version or content.date or things like that. Other content types could be represented that way also, and programs that show them just need to call the handler for that kind, or handle know files in the directory. Could be directories for users, and categories, could be files describing the security scheme for the current directory, a lot of things

This could have a lot of advantages, would be easier to backup, to the admin work with the information outside the system, to batch programs to get information, process, convert, etc. Will be simple to manage and to understand, and, at least at some level, to build a tiki system over it.

But, in the other hand, it could have disadvantages? Processing the data as a whole could be messy. Searching will need another way to be done... a grep on the tree will not be good, maybe submiting to an indexer the content attributes could solve the problem (the names of the files will have all the path to them, so giving a piece of content the proper place is in the name. Another problem could be speed, if for each part of a big listing you have to get a file with the date, a file with the owner and so on instead of just obtaining a row of a query record, well, speed could suffer (or not).

But, anyway, look a nice model to look over it and try to visualize how data could be represented or stored.

Or could give another idea about database abstraction. If things are properly structured, the database access part could be deep in the core, and outer modules will not talk directly with the database or whatever it is, but with the data access modules. What if at this level I put something that enables to choose how to store content, like in a sql database, a ldap directory or the filesystem?

I'm a bit old-fashioned in a lot of topics, prefer HTML 3, not do a lot of OOP, and am somewhat slow to adopt "new" things, so I don't discard without thinking the idea of storing complex information directly on the filssystem, but, what you think about all of this?