You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

nsFileSpec email thread
by Michael Ang <mang@subcarrier.org>

nsFileSpec allows manipulation of filenames in a platform independent way. This functionality should be used by the JS File object. The current thinking is to roll this functionality into NSPR, since the JS File object should depend solely on NSPR.

Email about nsFileSpec (slightly edited by mang): 

> Subject: [Fwd: nsFileSpec checkin.]
> Date: Thu, 10 Dec 1998 13:59:09 -0800
> From: Angus Davis 
> Organization: Netscape Communications
> To: Brendan Eich 
> 
> So, if this is XPCOM'd, why do I need the extra weight of the file
> object code?
> -angus
> 
> -------- Original Message --------
> From: John McMullen 
> Subject: nsFileSpec checkin.
> Newsgroups:
> netscape.public.mozilla.xpfe.checkins,netscape.public.mozilla.layout.checkins
> 
> >From the header file nsFileSpec.h:
> 
> //===================================================================
> 
> //
> //  Classes defined:
> //
> //      nsFilePath, nsFileURL, nsNativeFileSpec.
> //
> //  This suite provides the following services:
> //
> //      1.  Encapsulates all platform-specific file details, so that
> files
> can be
> //          described correctly without any platform #ifdefs
> //
> //      2.  Type safety.  This will fix the problems that used to occur
> because people
> //          confused file paths.  They used to use const char*, which
> could mean three
> //          or four different things.  Bugs were introduced as people
> coded, right up
> //          to the moment Communicator 4.5 shipped.
> //
> //      3.  Used in conjunction with nsFileStream.h (q.v.), this
> supports
> all the power
> //          and readability of the ansi stream syntax.  ALL METHODS OF
> istream, ostream,
> //          AND iostream ARE AVAILABLE!
> //
> //          Basic example:
> //
> //              nsFilePath myPath("/Development/iotest.txt");
> //
> //              nsOutputFileStream testStream(myPath);
> //              testStream << "Hello World" << endl;
> //
> //      4.  Handy methods for manipulating file specifiers safely, e.g.
> MakeUnique(),
> //          SetLeafName(), Exists().
> //
> //      5.  Easy cross-conversion.
> //
> //          Examples:
> //
> //              Initialize a URL from a string without suffix
> //
> //                  nsFileURL
> fileURL("file:///Development/MPW/MPW%20Shell");
> //
> //              Initialize a Unix path from a URL
> //
> //                  nsFilePath filePath(fileURL);
> //
> //              Initialize a native file spec from a URL
> //
> //                  nsNativeFileSpec fileSpec(fileURL);
> //
> //              Make the spec unique (this one has no suffix).
> //
> //                  fileSpec.MakeUnique();
> //
> //              Assign the spec to a URL
> //
> //                  fileURL = fileSpec;
> //
> //              Assign a unix path using a string with a suffix.
> //
> //                  filePath = "/Development/MPW/SysErrs.err";
> //
> //              Assign to a file spec using a unix path.
> //
> //                  fileSpec = filePath;
> //
> //              Make this unique (this one has a suffix).
> //
> //                  fileSpec.MakeUnique();
> //
> //      6.  Fixes a bug that have been there for a long time, and
> //          is inevitable if you use NSPR alone, where files are
> described
> as paths.
> //
> //          The problem affects platforms (Macintosh) in which a path
> does
> not fully
> //          specify a file, because two volumes can have the same name.
> This
> //          is solved by holding a "private" native file spec inside the
> //          nsFilePath and nsFileURL classes, which is used when
> appropriate.
> //
> //      Not yet done:
> //
> //          Equality operators... much more.
> //
> //========================================================================

Brendan Eich wrote:
> 
> JS occurs elsewhere from Gecko, or mozilla/base, or whatever this stuff
> ends up under.
> 
> JS needs a standard file-handling extension.
> 
> As Brent Welch and I were agreeing over dinner in New Orleans, it would
> rule if JS, TCL, Python, etc. could all share the effort that went into
> *one* file object implementation, rather than each re-inventing their
> own variations on that wheel, most or all of which are just retreads and
> wrappers around stdio/Unix-file-io.
> 
> Comments from xpcom and js-file-object heads welcome.
> 
> /be
> 

Brendan Eich wrote:
> 
> Bloat is bad.  Over-coupling JS to mozilla/base/src is bad.  But
> somewhere here there must be good.
> 
> Can you estimate (line count or other measure) how much duplication
> there is between jsfile.c and mcmullen's stuff?  Thanks,
> 
> /be

Mang wrote: 
> > I'm meeting with Guha next week to discuss RDF reflection into JS,
> > which would give us some free interaction the filesystem.
> >
> > In terms of code duplication, the biggest area is in filename
> > manipulation (~700 lines).
> >
> > The other 1500 lines in jsfile.c don't
> > overlap much with mcmullen's stuff.  mcmullen's comments says he's
> > fixed some problems with NSPR filenames, so I may need to incorporate
> > those changes.  Perhaps we could build JS File on top of mcmullen's
> > code?
> >
> > Having JS File be available even when COMConnect is not could be a win
> > for a standalone interpreter.

Brendan Eich wrote:
> 
> Could we get NSPR to do [filename manipulation] for us?
>
> I still think the coarse dependencies should be JS: NSPR and
> McMullenStuff: NSPR, and would prefer to avoid JS: McMullenStuff: NSPR.
> 
> If NSPR has problems, the nsprgroup (wtc at least) should get bugs or
> equiv. email and fix 'em -- did mcmullen say he'd done that?  If not,
> then shame.
> 
> /be

Wan-Teh Chang wrote:
> 
> Mike Ang wrote:
> 
> > John McMullen has put some wrapper code around NSPR that he says
> > fixes
> > some problems.  I'm currently working on a JS File object
> > (http://www.mozilla.org/js/js-file-object.html and
> > mozilla/js/src/jsfile.c) that has duplicated some of this code
> > (particularly filename manipulation).
> >
> > Could you please look at John's code and see if some of it should be
> > incorporated into NSPR?  I would rather not duplicate any code and the
> > JS File should be dependent on NSPR instead of mcmullen's code.
> 
> We can't  incorporate John's code into NSPR because
> his code has a C++ API but NSPR has a C API.
> 
> By the way, you should send NSPR feature requests to
> our product manager Basil Hashem.  (Our divlet is
> implementing a formal development process.)
> This item is already on his NSPR PRD draft, but you
> can still point him to your implementation in Javascript.
> 
> Wan-Teh
> --
> My opinions do not necessarily reflect the opinions of my group.
> 

Brendan Eich wrote:
> 
> Surely something written in C that provides the missing or commonly
> needed functionality could be added to NSPR?  I'd volunteer to translate
> any C++ that John wrote, if everyone agrees that the functionality ought
> to go in NSPR along with the existing PRFile* API.
> 
> In case it wasn't clear, we don't want JS to depend on John's code
> directly because core JS is a C engine that depend only on NSPR, and has
> many users who will or can not swallow a new dependency.
> 
> /be
Created by Michael Ang
Questions should be directed to Norris Boyd
Last modified: Fri Dec 18 20:34:31 PST 1998