Built-in VFS

Summary of points taken from VFS. See that page first...

During initialisation, Tcl needs to: find some encodings (particularly the platform-native one: macRoman, cp1252, or iso8859-1 as appropriate), otherwise it is really lost. It also needs to "source init.tcl". If we look at this from the 'vfs' perspective, it also needs to initialize at least one filesystem (from which it can get those files!), but that filesystem need not, in principle be the native filesystem, or indeed anything which looks like the native filesystem at all (for a very, very minimal, embedded system, it could even be a very hard-coded thing which just knows about the native encoding and init.tcl and nothing else, or it could be a networked filesystem which has to find those resources remotely!).

So, minimally, Tcl needs to:

• call a 'TclInitFilesystem' function, the result of which must be that at least one filesystem is hooked up, and that at least one 'absolute' path (or 'volume') exists.
• later attempts to find encodings and init.tcl succeed.

(of course one could imagine entangling these two steps into one, but that seems like a bad idea to me, so I'm going to ignore it).

So, the tricky bit is really defining these two things appropriately, so that the whole encodings/init.tcl search process continues to work if the native filesystem is used as in current tcl versions, but that it also works if some new filesystem is hooked in instead. This may mean that the logic of searching used for encodings and init.tcl needs to be modified a bit.

Issues to address: where do we look for encodings and init.tcl?

Of course we need an absolute path to exist, but if the first step doesn't hook in the native filesystem, then '/' (on unix) will not exist. This means whatever other filesystem is hooked in must create a different absolute path. For example 'tcl://' is one interesting possibility.

We could assume the existence of tcl://boot.tcl and define startup to source that file.

But this would mean that ordinary Tcl would also have to have that filesystem hooked up as well as the native one, which means that things like 'file volumes' always lists 'tcl://' as one available volume, etc etc. Do we want to expose the user to that? Of course one could later unregister the tcl:// filesystem if we don't need it anymore...