Cy/VOS Community Wiki | User / LogicalDiscStructure

Author: Telcontar
Category: Prop/SystemProposals
Ideas: Telcontar, StevMX, Mac OS X directory structure
See also: User/SettingsStorage
Status: Draft

Introduction

Firstly, let it be said that this article is not as coherent as it could be. I am purposefully leaving it in this format to show my lines of thought, even those that I have gone back on, in that they themselves might be more helpful than mere conclusions. This way, readers are able to follow them and see where I was going even if I then took a different course, as I might have been more correct to begin with.

Now, StevMX and I have had some interesting thoughts about the way in which one might arrange the logical structure of the disc. The most interesting thought that he had was that instead of having programs ask for literal paths, programs could ask for logical paths instead. In the same way that "~" in UNIX takes you to your home folder, all other folders could be addressed in this manner, e.g. "@settings/" for the program's settings folder, "@docs/" for the user's documents folder, "@temp/" for temporary files etc.

By doing this, it allows for system control (for OS flexibility) and user control in terms of how the disc is mapped out. It also prevents the kind of chaos that can ensue when programmers cannot decide where to put anything, often seen in Windows with programs that install to C:\NAMEINCAPS or dump stuff in the home folder instead of Application Data folder.

OS Private Space

Part of this would involve walling off parts of the file system as OS private space. OS Private Space is a type/name-mapped region system for all manner of data belonging to software and its dependencies. For example, each program installed by a user will have a Private Space settings folder of "@settings/", which may map to "/Users/foo/Private/Settings/Program Name". By shielding programs from the exact location and controlling the name and location specifically, it will prevent settings from becoming the sort of mess they can end up in on file-based systems (especially Mac OS) where programs create various randomly named settings files that are left behind when the program is deleted. This way, the only possible name to mix up is the package name which becomes the folder name. But most software is very happy to identify itself, it's just the files it creates that mean nothing.

Another Private Space folder would be Private/Deps for dependencies, but this folder would be located inside the system folder (/System/Private/Deps), such that any dependency need only be on the system once. Note that putting it in the global Private Space does not mean it will run as root of course.

The ~/Private folder ("@privateroot/") would be accessible to privileged users of course, who need to work with it to fix programs and do development; it would be completely hidden from standard users. The folder "@docs/" would map to what the user sees as their home folder, or /Users/foo/Home/.

Decentralised settings storage

Some settings may not be suitable for storage in a central settings folder, such as folder view settings and thumbnails. See SettingsStorage for some notes on this one.

Other standard locations

These are some suggestions for default disc mapping for Cy/VOS.

/System/ - the operating system: kernel and system software etc. Also all global Private data shared across users.
/Daemons/ - daemon-privilege area (for processes of group 'daemon'), for file and network services. e.g. /Daemons/WWW/ (Web server), /Daemons/FTP/ (FTP server) etc. Each hosted site's root folder would be contained in the parent folder (e.g. /Daemons/WWW/cyvos.net/) although symlinks might come into play for sharing FTP, file and WWW spaces.
/Users/ - user home folders.
/Apps/ - software available for all users

These would all be themselves mapped to their physical locations of course. I am not sure how to handle volumes by default. They could all just mount to /Volumes/, but being a Mac die-hard, I love the volumes-at-root idea where volumes are just folders at the root. But that ties you into paths like, on my machine, "Alder:System Folder:" for my system folder - the volume name is part of the path which is not good. Either this has to go, or you could make all of the standard paths also mappings, e.g. "@!System/", "@!Daemons/" etc.

Does this help any?

Applications

In writing SettingsMigration and SettingsStorage I became even more aware of the problems regarding applications that some people face. Windows software and some Mac software has a tradition of believing that it is single-user. mIRC logs... go in the mIRC folder in Program Files (by default anyhow, I suspect you can change this!). Winamp skins... go in the Winamp folder in Program Files. Gaim plugins, in the Gaim folder in Program Files. This is of course completely ludicrous for a supposed multi-user OS. UNIX prefers to just clog up your home folder with scores of .this_that_and_the_other folders that end up a real mess.

Mac OS X has tackled this with a fascinating folder called ~/Library/Application Support/, in which you can install any plugins, scripts, sound and icon packs etc for software giving every user a totally separate configuration space for even software installed as root for all users to share.

The binaries themselves

How about the application binaries? Of course, a user will be able to run – with adequate permissions – any program from any folder. However, this is going to clutter up your Home folder a lot. I wonder if a user "@Apps/" folder could also exist (as ~/Apps and by default invisible the same as ~/Private), into which programs get created. Programs would be automatically read by the OS and any launch system can register to read the list of programs in /Apps and ~/Apps.

(and, with a system like as in DependencyManagement, this could be used to maintain only one copy of each version of each program on disc, in /Apps. This is probably going a bit too far now :)

Settings structure

This then poses a matrix problem, the bane of computing.

          Mode:     Settings  |  Support    |  ...
       /--------------------------------------------
 App: | MicroChat   ...          my plugin
      | Atreides    ...          extensions
      | ...

As illustrated, files for each program on disc are accessed by effectively a grid reference of program and type. This leads to two approaches (where:

 ~/Private/AppData/*/Settings
 ~/Private/AppData/*/Support

and Mac OS X's style:

 ~/Private/Settings/*
 ~/Private/Support/*

The former makes more sense in that files of the same program all live in the same place, meaning that there's less chance of stray folders being left behind, and it's easier to visualise. Settings and support are still separated for sanity.

But honestly, if the app folders are to also be hidden, there would not even be any harm in storing settings directly in their own folders, as ~/Apps/*/Settings and ~/Apps/*/Support. The reason I originally thought about ~/Private was simply to work around the issue of having personalised copies of settings, but if apps also exist in each user's own folder, that is no longer a problem.

Removable media installation

Another consideration is that wherever the settings files get written, programs installed onto removable media need to have their settings written onto the removable media volume so that they remain with the program at all times, regardless of behaviour defined for normal installs. The app needs to be able to determine where to find its settings -- although I am told that Flash is too fragile to run settings from.

Access needs

Now, this is assuming that users never need to access any such folders. Currently, users home folders have been considered to be mapped to ~/Home, to hide the lower levels. I wonder if in fact this is a little unwise? On the one hand, it makes it easier for less experienced users to deal with (less visual clutter to shut out or accidentally break) yet it also stops people manually deleting settings files, popping support files into program folders (e.g. skins, sound sets etc). One could argue that all support files should come properly packaged (for users who really never ever want to have to see lower-level folders), and that this would stop people being lazy; it also suggests the need for a sane package maker that makes simple packaging, simple, e.g. for a plugin for an app, nothing more than:

 * -> "@apps/My App/Support/"

or:

 * -> apps("My App").support

if you like alternative syntax (frisky time).

Now, the next section introduces ways to customise exactly what folders are visible inside users ~ folder, so of course the above issues need not ever be answered, it could depend on distro, user level on user creation (eitiher privilege level or experience level associated with the account) and personal choice. That said, if you have too many variations it's going to become a nightmare for adminstration as no-one will ever know where any of the folders are. Abuse of custom views is not recommended, it's only good for specialised cases.

Simple and custom views

Some users really don't want to have to learn to understand disc structure, and the present concept of a root-centric disc structure is not helpful. Even more familiar users are wont to do things like clean out all the "unwanted" files from C:\ and other such folders.

I wonder if, for the most basic users, a home-centric structure wouldn't hurt. So instead of having your files at /Users/bob/Home/, "@Home/" would be mapped to a virtual root. Thus, opening a disc browser at "/" would just show the home folder and nothing more. Seeing as many people never need to see any more than that, it would protect them from one of the sources of intimidation, untidiness, and plain worry. Deep drive hierarchies are fun for the likes of me, but most people don't need or want to know, it just confuses them.

This gives an interesting example of how a set-up might work overall, and how the @ targets work. For example, a simple office set-up for normal users might be:

 virtualRoot: /Users/*/Home
 defaultMappings: {
  /Volumes/LAN/shared/Publicfolder > "/Office public" +w
  /Volumes/LAN/access/Templates > /Templates -w
 }

This makes the root folder be the user's Home (a very tranquil view), and places two networked folders directly into it. Now, software trying to access ~/Private etc would be majorly screwed up by this set-up, as they no longer exist. However, "@settings/" is still mapped appropriately internally, as is "@temp/" and so forth, so software using these would work just the same as ever.

I don't quite like this layout; the root no longer has a user-recognisable name (something that calls out "put files in me") and network folders are being mounted inside of home, which worries me (fun if you get a naming conflict!). I'd prefer:

 virtualRoot: null # make the root point nowhere
 defaultMappings: {
  /Users/*/Home > "/My files"
  /Volumes/LAN/shared/Publicfolder > "/Office public" +w
  ...
 }

That way, the root no longer has any ability to store files and files are all put somewhere nice. Write access to / would result in the error, "This %1 needs to be stored inside a folder on the system, e.g. My files" (the latter being read from somewhere... but where?)

I guess you could create a /Users/*/Private/VirtualRoot folder and map virtualRoot to that if you wanted...

The goals

Of course, the above is just a theory of what you could use. the first paragraphs of the page explained programmatic reasons for this level of abstraction. Another advantage, and one of the most useful goals here as far as Cy/VOS is concerned, is having neither users nor software tied to any particular disc structure (the path configuration examples merely being the tip of the iceberg) (I shall resist a Matrix quote here). Cy/VOS doesn't really want to be tied to any disc structure insofar as it wants to remain untied to any particular purpose or target userbase.

Of course, higher-priveleged users will of course just bypass any simplified views and see the disc structure for how it really is. Software cannot make any assumptions at all, unless it too is running as a priveleged process and is intended to work with disc content unmapped.

Something like that anyhow.

What I don't want to see, though, is a ridiculously complicated drive structure like Mac OS X, where the contents of ~/Library go on like catacombs for miles and could be very intimidating, where you can have two different Application folders (one root for all users, often non-writable, and one local for your own stuff, good luck remembering where each program is), where settings never get cleaned up and where the System folder itself is the most awful mess of junk.

I would like Cy/VOS try to recapture the idea of a disc structure that's simple, sweet and anything complicated gets wrapped nicely. Much easier to find the tree in the grove, than the tree within the forest... If a particular module, extension or program is going to be full of files, package it into a single file. Mac OS X allows this for software and user programs, but the rest of the system doesn't make use of this it seems.

Navigation

LogicalDiscStructure

Contents