В Втр, 09/06/2009 в 11:27 -0600, andrey mirtchovski пишет: > I think I've mentioned this before, but on a few of my synthetic file > systems here I'm using what you describe to slice a database by > specific orderings. For example, I have a (long) list of resources > which I'm managing in a particular environment each has an owner, > type, status and a few static data containers. It's all backed by a > relational database, but the file server presents different "slices" > of that to external users, where the directory structure is rigidly > defined as: > > / > available/ > by-type/ > by-owner/ > inuse/ > ... > > with all data to fill the directories being dynamically pulled from > the database.
This looks like a slightly different use case than what I'm worried about. Mainly it seems that you don't really have to deal with the representations of the same resource, your problem is how to group these resources in a reasonable fashion. Essentially you're mapping a relational database to a tree hierarchy. In your case, the sooner you have the fork of by-this/ by-that/ .... in your hierarchy -- the better. My case is a flip side of that. In fact, my worst case scenario is that I can't really predict all the representations of existing resources down the road, thus it appears that I have to push that part of a filename as close to an actual file as possible: /long-path/file.<representation> I'm almost tempted to consider "virtual extensions": /long-path/file ## default representation /long-path/file.gif .... /long-path/file.pdf but at that point it becomes no more appealing than the content negotiation techniques of HTTP. Thanks, Roman.
