>From: Beman Dawes [mailto:[EMAIL PROTECTED]
>>There are a bunch of reasons - but particularly it would be creating
>>names that will just be rejected by many (or even most) modern operating
>>systems. What would be the point of that? It is the same as with requests
>>for allowing full URI syntax in paths; without any mechanism in the
>>operational functions allowing those paths, what would be the point?
>
>The point is that there is a common need for parsing, combining, and
>otherwise manipulating URI and other paths prior to forwarding them to
>another system that processes that format. This may not be a mission of the
>filesystem library, but it is an important use case.
I gave that some consideration at one time, but the full URI spec (http://www.ietf.org/rfc/rfc2396.txt) covers so much that is totally outside the scope of a filesystem library that it really seems an over-generalization to try to included it as part of filesystem::path. The tail would soon be wagging the dog:-)
A separate URI library would seem a cleaner approach.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
