-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2005-03-16 06:06:11 +0000 Sheldon Gill <[EMAIL PROTECTED]> wrote:
I've a range of "problems" regarding GNUstep in respect to the file system, some of which are wishes for better behaviour but some are certainly what I'd categorize as bugs. These "wishes" aren't restricted to the windows environment either.
Perhaps starting with reporting individual bugs would make sense ... since they generally only get fixed if people know about them, and a problem broken down into individual parts is much easier to deal with.
Some of the ideas discussed have begun to be implemented in stages. I wouldn't call it most and definitely not all.
At the path handling on windows, essentially the issues arise because
OpenStep -> POSIX -> (emulation) -> Win32
is the current layering and that introduces all sorts of issues as we move from layer to layer. The "impedance mismatch" gets compounded and we add both overhead and complexity in the process.
Unicode compounds the issues. Especially as there are Unicode issues
with mingw and msys. I'm not sure what exactly has been fixed for the latest release but definitely are there for earlier ones.
Internally, the current -core code has some parts working with unicode strings for the file system while other parts don't.
I see support for unicode filesystem as a strong wishlist item... it's not part of OpenStep, but I feel we should add it since my guess is that the windows implementation of the the posix functions used in a lot of places does not handle it.
After quite some investigation I believe the best way is to go
OpenStep -> Win32
as far as possible. This means that all things should be in UTF-16 and left untransformed as far as possible and reasonable.
I'm not sure what you mean above ...
If you simply mean that we should use win32 api calls directly (eg CreateFile() rather than creat()), then I think that's uncontroversial and is the direction we are moving in for the sake of performance and aesthetics. One thing that bugs me about current code is that, because it was written by a variety of unix people, it uses fopen(), fread() fclose() etc in a lot of places where it should realy be using NSFileHandle/NSFileManager to encapsulate system dependencies. Thats' not to say that the existing code is buggy in any way, just that it's less easily maintainable/portable than it might be.
The only transformation which should be done is variable expansion on paths read from the environment/registry so that absolute paths are used internally in their native form.
This is the safe, sane and future compatible way to go. Least harm, smallest set of assumptions. Leads to least code and smallest overhead.
This does lead to some issues with the path handling NSString methods
which need to be considered but they aren't show stoppers. There really just needs to be some consideration and handling of the non-POSIX Win32 case where:
"\" is the separator
"/" isn't the FS root
symlinks don't exist
"~" is meaningless
I think on this point you are asking to break GNUsteps OpenStep/MacOSX compatibility and ignore the userbase of programmers wishing to write portable code.
OpenStep was designed for/from a unix worldview and has an API reflecting this.
As such it's my opinion that failing to transform strings (for instance to use '/' as the path separator internally) would break things and would force users (by which I mean people writing applications) to write more code with larger overheads because they would end up writing code to allow for differences in path semantics at the application level rather than the library level.
So, while it would indeed be 'safe, sane, future compatible, least code, smallest overheads' internally withing the base library, it would be the exact opposite for users of the library who would have to write more code to make their apps portable between unix/windows, would have to understand the assumptions of both filesystems, and would need to know about new filesystems in future... this is not the sort of programming environment we want to provide. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail
iD8DBQFCN91sE6AJp3nmKIkRAh+bAJ4yll37mcc3e+BTPXLGSnE5NoYzrACg1Jy4 Ux/X3+ID8NdT8IS1af3T9pk= =zm2J -----END PGP SIGNATURE-----
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
