Re: Proposed nsIFile and nsILocalFile Changes - MUST READ

[Frank Yung-Fong Tang]

Doug Turner wrote:

[EMAIL PROTECTED]">

Mike Shaver wrote:

Doug Turner wrote:

Removing explict symlink function.

As someone who spent many hours fighting in the symlink-semantics wars,
I really want to hear an excruciating clear description of what happens
when various types of links (to files, to directories, dangling) are
operated on in various ways.

I too have had to wrap my brain around all the issues with xp symlinking.  The
root problem that we tried to make windows and the mac do auto resolving.
This sucks cause on these platforms, it is expensive and ugly to try to
resolve links.  Without digging to deep, I want to see the mac and window
nsLocalFile impl knowing NOTHING about symlinks implictly.  There will be a
call on the nsIFile (or in that file system service) that will resolve only
the terminal node and either return a new nsIFile or modify the current
nsIFile.

This is much simpiler than what we have now.

The biggest change is that nsIFile and nsILocalFile should be split into
two logical pieces: file description and the file system service.  The
first piece would just be basic filepath manipulation, initalization,
and stat getters.

stat is a filesystem operation, I think, unless you want to generalize
it to apply to all path-like things (file: URLs? all URLs?).  nsIFile
should be about filepath mechanics, and anything that interacts with a
filesystem (or moral equivalent, in the case of remote URLs) should be
in the other service.

right.  I think that is what I said.  Two parts:  A state part and a function
part.

And while you're moving that stuff around, I think it's _imperative_
that we fix the current issues with stat caching and the like: stat data
should be reflected in another interface, which will permit the API
consumer to make stat calls efficiently, and provide
as-atomic-as-possible access to the data in question.  There's a bug
about this somewhere, but I can't find it at the moment.

what problems? Please dig up some bugs.

The first additional comment is that we should remove the non unicode
version of all methods.  I believe that i18n will be happy with this.
However, I am not sure how this will effect most users.  Looking over
the codebase, most places we are dealing with unicode anyways, however,
there may be places which will have to convert from ansi to unicode.

I second Jon Smirl's concern over the fate of XPCOM_STANDALONE, and am
somewhat saddened to see that we want to make our whole product bear the
memory and computation burden of UCS-2/UTF-16 paths when the _vast_
majority of our paths live happily in 7 bits.

CCing ftang.
Frank, you added unicode paths to the nsIFile.  A couple of questions:

[EMAIL PROTECTED]">

Why do we need unicode paths on the nsIFile?

File name do contains non ASCII characters. And in general we should use wstring / PRUnichar* for all XPCOM interface for any text which are human readable. We also want to hide the details of what charset are used in the file system from the caller.

[EMAIL PROTECTED]">

Can't consumer convert before calling into this interface?

The problem is the string class in JavaScript is Unicode. Once the interface are declare as string instead of wstring, the JavaScript engine will cast down the array of PRUnichar to char one by one- which will cause data lost. That is why we should use Unicode in the interface.

[EMAIL PROTECTED]">

  Can we have macros
outside of this interface?

Can you do macro in JavaScript ?

[EMAIL PROTECTED]">

What about callers from JS via xpconnect, what charset are those paths used
when being converted to char*'s?

That is the problem, we want to hide the details of what charset used by file system inside this class instead of let the caller find all the information- which is very confusing and need to change a lot of call. When I add those Unicode methods, I try to keep it as close as the origional code so the only thing we need to change from the caller side is the function name.

[EMAIL PROTECTED]">

--

Frank Yung-Fong Tang Sr. Technical Manager Netscape Communications 譚永鋒 資深技術經理

Tel:650-937-2913 Fax:650-937-5413 mailto:[EMAIL PROTECTED] http://people.netscape.com/ftang AIM:yungfongta