RE: [boost] Thought on paths

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-29 09:12:50

From:	Ken Hagan [SMTP:k.hagan_at_[hidden]]
> 
> From: "Jason Stewart" <res0054p_at_[hidden]>
> > 
> > However, if the application specifies a path as "myfile.foo" then 
> > the library should not prevent that.
> 
> I think we have to ask why an application would do that. The most
> likely reason is that the application's author was brought up on
> UNIX or Windows and thinks that "myfile.foo" is an acceptable name
> for a "foo" file on any platform. This isn't true, and the library
> interface should encourage the application author to specify the
> "myfile" and "foo" components separately, so that they might be
> handled appropriately.

If you're using the Unix/Windows pathname manipulation class, then
myfile.foo is quite appropriate.  If you're using the Mac OS X pathname
manipulation class, then you wouldn't supply myfile.foo at all, from my
understanding.

> > If the application specifies a filename as mypic.jpeg then DOS
> > would simply use mypic.jpe. We cannot translate this to 
> > the more reasonable mypic.jpg because we don't know enough about the 
> > application.
> 
> This is indeed hard, but not impossible. If the program exists to
> write files of this type, I would expect whoever ported it to MS-DOS
> to provide the correct extension. If, on the other hand, the filename
> came from the user, we could probably trust the user to specify the
> correct extension.

Right.  This isn't the responsibility of the pathname manipulation class.

> > See Darin's message for more information but my understanding is the 
> > original application could not open the file but you could still open
> > it at a lower level using the C++ fopen for instance. However, this
> > is manipulating the file, not the name.
> 
> Yes, I saw Darin's reply. However, if my application writes a JPEG
> file, I think it is reasonable that the end user should be able to
> use it as a JPEG file. Principally, that means they should be able
> to double click on it and launch the correct application.

That means that the class that creates a file in the filesystem must know
how to map the supplied pathname to something appropriate for that
filesystem.  Again, I don't think this is the responsibility of the pathname
manipulation class(es).

> > As much policy as possible should be pushed into policy classes I
> > think.
> 
> That's easier said than done. Someone else has already pointed out
> that an OS might support several different file systems, and even
> if it didn't, users will still want to be able to manipulate files
> on alien machines elsewhere on the network.

Jason is suggesting a class template that is given one or more policy class
to control its behavior.  When working with a Unix filesystem, whether on
the local machine or on the network, one would use the Unix pathname
specialization.  When working with a VAX filesystem, one would use the VAX
pathname specialization.  Provided the interface is well chosen, it seems we
can find sufficient commonality among most filesystems to allow one class
template, and a set of policy classes, to provide a common interface.

Whether such a framework works with URIs as its internal format, manages a
complete string in some chosen filesystem format, or stores the path
elements separately is not terribly important at the moment.  Perhaps we
rely on one or more policy class to do all of the path manipulation for a
given platform, relying on the class template to coordinate everything in a
common way.

Nevertheless, we need a simple way to manage paths on those systems that
support paths.  When filesystem classes are designed for the various
platforms, those should rely on the pathname class(es), when appropriate.
Thus, one might not be able to create a Mac file object from a pathname
object, whereas one could create a Unix file object from a pathname object.
These are different layers of a framework, with different requirements.

Rob
Susquehanna International Group, LLP
http://www.sig.com