At 03:16 17/08/04 -0700, Krasimir Angelov wrote:
Maybe - although the conventions still differ between Unix and Windows. On Unix, to store per-user data you would use <homedir>/.<app> whereas on Windows you use <homedir>/<app>. So I think the win32 library should provide access to getAppUserDataDirectory, and the app code still needs to be conditionally compiled.
Instead we can provide function like:
getAppUserDataDirectory :: String -> IO FilePath
where getAppUserDataDirectory "<app>" will return <homedir>/.<app> or <homedir>\<app>
If we're going this way (which I think is a good thing), I think some more generic path query functions could be useful. When I ported the HaXml+HTTP libraries to windows, I needed to be able to find the current directory in order to convert a filename into a file: URI, in order to provide uniform handling of external entity access and base URI handling. The logic I used is somewhat ad-hoc, and can be seen here: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXm... (See function "unsafeGetExtEntity".) There's some related logic I did for Hxml Toolbox to establish a default base URI: http://www.ninebynine.org/Software/HaskellUtils/HXmlToolbox-4.00/hparser/Xml... (see function "setDefaultURI".) All this raises questions about the correct correspondence between file: URIs and local filesystem names, which I've raised as a discussion point on the mailing list dealing with URI standardization: http://lists.w3.org/Archives/Public/uri/2004Jul/0009.html with some follow-up in a different thread: http://lists.w3.org/Archives/Public/uri/2004Jul/0013.html ... Anyway, I'd like to see the common library functions provide at least minimal capabilities to allow multi-platform applications to do the right thing when handling filenames. I'm pretty agnostic about what they actually look like, but as an example I've found the Python and/or Java libraries to be pretty usable in this respect. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact