Hi Chromium Developers,

I'm working on Google's O3D (http://code.google.com/p/o3d), and we
(naturally) share some of Chrome's base classes for our code, including the
very useful class FilePath.

However, in using FilePath in the last few months, I've seen that it needs
some refinement.  I'd like to augment the FilePath class with some things
that would make it more generally useful -- it's very nicely set up, but
it's missing a few things that make it harder to work with than it needs to
be:

1) I'd like to add some explicit routines for converting to/from UTF8 and
UTF16.  While it's nice (and important) that FilePath uses the platform's
native string, we've found that many third party libraries have made other
assumptions, where they always expect UTF8 (char) or UTF16 (wchar_t) paths
regardless of platform, and converting a FilePath to and from those forms is
a platform-dependent exercise which should be centralized into the class
(i.e. adding "ToUTF8" and "ToWide" functions to the class, and explicit
constructors that take each type).

2) I'd like to make it possible to instantiate a POSIX FilePath object on
Windows and a Windows FilePath on POSIX platforms.  This is because some
libraries (e.g. the zip library, or tar files), use POSIX semantics for
their paths even on Windows (I haven't seen a use case for Windows paths on
POSIX yet, actually).   This would make it possible to use the nice API that
FilePath has to manipulate paths appropriately for these other libraries.
This could be easily accomplished by having POSIX and Windows versions of
FilePath, and then typedef'ing FilePath differently on different platforms
to one of these versions.

3) It would be helpful to have real path normalization for each of the
platforms (although I know what a testing nightmare that can be).  I might
try and tackle this if people think it would be beneficial.

4) Make sure we handle case sensitivity vs case preservation correctly.
It's unclear to me that FilePath does this correctly on the Mac -- Mac file
names are case preserving, but case insensitive, Unix filenames are both
(and windows filenames are neither :-).

So, is there any resistance to any of the above?  Do you have other
suggestions that I might take into account?  Am I violating any design
assumptions of FilePath?  For #2, is speed/size enough of a concern to avoid
a virtual base class (I wouldn't think so, but you never know..)?

-Greg.

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to