Re: [boost] Filesystem Library mini-review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-01-06 16:51:00

At 02:35 PM 1/5/2003, Sean Parent wrote:

 >on 1/5/03 10:21 AM, Beman Dawes at bdawes_at_[hidden] wrote:
 >
 >> I had a conversation with Bill Plauger, Howard Hinnant, and several 
other
 >> library implementors at the last C++ committee meeting, and we agreed 
on
 >> a possible approach to the conversion problem. Conversions between wide
 >> and narrow names has always been the hold up. No one has been willing 
to
 >> step forward and say "Of all the possible ways to do the conversion, 
here
 >> is how libraries should do it."
 >
 >Rather than using simple path specifier (which I think are a very limited
 >way to refer to a local resource) - why not make the path syntax be URI
 >based? There is already a W3C proposal for extending URIs to be fully
 >international friendly (IRIs) -
 ><http://www.w3.org/International/iri-edit/>.
 >This would also allow for relative references, remote references,
 >authentication, versioned file systems (such as WebDAV
 ><http://www.webdav.org/>), and query references to database file systems.
 >
 >I would rather see going with an existing standard than inventing yet
 >another way to refer to resources with international names.

Sean,

I think you may have misunderstood the context, although 
internationalization issues are confusing enough that I may be the confused 
one. Here is my understanding of the problem.

The syntax, semantics, and about everything else about paths that operating 
system functions traffic in was defined years ago for each operating 
system, standardized or not. Those native path formats aren't something we 
can change.

Likewise, higher-level generic path formats have been nailed down for years 
by POSIX, RFC2396, etc. That's why the Filesystem Library's Generic Path 
Grammar was chosen as a subset of those standards.

For boost::filesystem::path, any other path handling facility, the need 
arises to convert a path between narrow and wide character strings. For 
example, the operating system may use narrow character paths but the 
program traffics in wstrings. That causes a need for conversions, and if I 
understand correctly, there are a number of ways (all conforming to one 
standard or another) to do that conversion, and it is really messy because 
of locale issues. PJP is well aware of those standards; indeed he wrote 
some of them, and IIRC has been to Japan and other Asian countries more 
than twenty times dealing with internationalization issues.

So the problem isn't to "invent yet another way to refer to resources with 
international names".  Rather, it is a need to be able to convert to 
between  existing ways to reference resources with international names.

--Beman