> Christian Lynbech writes
> What I was thinking was something in the style of the CL path
> abstractions such it would be possible to write code which was
> insensitive to the underlying type of filesystem.
That would be definitively useful.
> Thus you would have filenames and paths expressed basically as lists
> of elements which could be collected by various functions to either an
> MSDOS or UNIX style filename. Not only would this remove the burden
> from the programmer, but also allow various configurable choices to be
> made, for instance in how to map in the drives or how to truncate
> filenames to 8+3. Users may have different tastes in some of these
> respects.
>
I'm not sure that a list representation would be the best (external) solution.
I'm pretty sure that people would not use it (they will imho continue to
express file name as strings since this is the way they always do).
One way which would be (perhaps) interesting to investigate is to use a
URL notation for naming files. After all, I have well understood, this
notation
allow to express file name independently of the running system. I must admit
that I have not read the document which specify this (i even don't know where
I can find it) but I suppose that there is a standard way to express that a
file is on the G: disk of a Win32 http server. Maybe I'm wrong, but if this is
the case, it would be also interesting to extend open such as it will take
into account the file transfer protocol. In fact, the interpreter could use
"file:"
as a default and we can have specialized (dynamically loadable) extension for
"ftp:", or "http:" files. This would probably provide a simpler interface
for user.
BTW, can someone tell me how I would express the URL of file bar in the
directory foo located on disk C (on Win32 and Mac system)?
-- Erick
Received on Thu May 23 1996 - 10:47:09 CEST
This archive was generated by hypermail 2.3.0
: Mon Jul 21 2014 - 19:38:59 CEST