Closed Bug 99160 Opened 23 years ago Closed 22 years ago

Freeze nsIFile

Categories

(Core :: XPCOM, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.0

People

(Reporter: dougt, Assigned: dougt)

References

Details

(Keywords: embed, topembed-, Whiteboard: [fixed trunk])

Attachments

(1 file, 5 obsolete files)

nsIFile
    * Requires: nsISimpleEnumerator
    * To Do
    * The implementation of NS_GetSpecialDirectory(...) should probably be moved
out of this IDL file.

nsILocalFile
    * Requires: nsIFile, NSPR I/O

nsIProperties
nsIDirectoryService
    * Requires: nsIDirectoryServiceProvider
nsIDirectoryServiceProvider plugin requirement.
Blocks: 98278
Target Milestone: --- → mozilla1.0
Keywords: mozilla1.0
Depends on: 94323
nsIDirectoryService is frozen.  adjusting summary
Summary: Freeze nsIFile nsIDirectoryService → Freeze nsIFile
Depends on: 121179
Depends on: 122506
No longer depends on: 122506
Keywords: topembed
Keywords: mozilla1.0+
Keywords: mozilla1.0
Depends on: 12911, 127098
Depends on: 57995, 129279
No longer depends on: 57995
Depends on: 124002
Posted on the newsgroup:

With less than three weeks left or so before Mozilla 1.0 (according to the
Mozilla Road Map), and a requirement that nsILocalFile be frozen, I propose that
we mark theses interfaces as FROZEN as-is.

Please send your flames and offers to help to dougt@netscape.com, or better yet,
use the tracking bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=99160
Doug,

Please, before mozilla 1.0, re-commit the changes that you made in revision 
1.48 of nsIFile (moving the inline NS_GetSpecialDirectory into a separate file 
and wrapping it in '#ifndef MOZILLA_STRICT_API').

Without this change, the purpose of MOZILLA_STRICT_API would be defeated: a 
client would end up having to include the 'obsolete' ComponentManager and 
ServiceManager headers before including nsIFile.
Yup.  

revision 1.49
date: 2002/01/29 21:42:38;  author: dougt%netscape.com;  state: Exp;  lines: +46 -36
Backing out nsIFile changes which should not have landed.  


As Mark mentioned, this needs to happen before the interface is frozen.
Comment on attachment 74847 [details] [diff] [review]
Moves utility function into header file

sr=rpotts@netscape.com
Attachment #74847 - Flags: superreview+
Comment on attachment 74847 [details] [diff] [review]
Moves utility function into header file

r=jband
Attachment #74847 - Flags: review+
Comment on attachment 74847 [details] [diff] [review]
Moves utility function into header file

Why is the new file named with the nsI prefix?	It defines no interface, in
particular it does not define nsIFileUtils.  Rename it to nsFileUtils.h, or
perhaps nsSpecialDirectory.h?

/be
Attached patch patch v.2 (obsolete) — Splinter Review
new file name is nsDirectoryServiceUtils.h
Attachment #74847 - Attachment is obsolete: true
Those patches look the same to me, and to diff. :-)

/be
Attached patch attempt 2 of patch v.2 (obsolete) — Splinter Review
Attachment #74872 - Attachment is obsolete: true
Attached patch attempt 3 (obsolete) — Splinter Review
I think we have a problem if this does not work!
Attachment #74878 - Attachment is obsolete: true
Attached patch attempt 4 using Nav4.7 (obsolete) — Splinter Review
There is a problem with 0.99.  I could not get the file://path_to_patch/patch
to notice my changes.
Attachment #74879 - Attachment is obsolete: true
Comment on attachment 74880 [details] [diff] [review]
attempt 4 using Nav4.7

Carrying forward r= and sr=, adding a= for 1.0 checkin -- good file name!

/be
Attachment #74880 - Flags: superreview+
Attachment #74880 - Flags: review+
Attachment #74880 - Flags: approval+
dougt: make sure jkeiser is aware of the problem you were seeing... it may be
some side effect of the new form POST implementation.
i tried to reproduce the problem but could not.  Thanks for pointing me at jkeiser.
That last patch was checked in.

Checking in MANIFEST;
/cvsroot/mozilla/xpcom/io/MANIFEST,v  <--  MANIFEST
new revision: 3.24; previous revision: 3.23
done
Checking in Makefile.in;
/cvsroot/mozilla/xpcom/io/Makefile.in,v  <--  Makefile.in
new revision: 1.60; previous revision: 1.59
done
Checking in makefile.win;
/cvsroot/mozilla/xpcom/io/makefile.win,v  <--  makefile.win
new revision: 1.50; previous revision: 1.49
done
RCS file: /cvsroot/mozilla/xpcom/io/nsDirectoryServiceUtils.h,v
done
Checking in nsDirectoryServiceUtils.h;
/cvsroot/mozilla/xpcom/io/nsDirectoryServiceUtils.h,v  <-- 
nsDirectoryServiceUtils.h
initial revision: 3.1
done
Checking in nsIFile.idl;
/cvsroot/mozilla/xpcom/io/nsIFile.idl,v  <--  nsIFile.idl
new revision: 1.51; previous revision: 1.50
done
here's a preliminary patch for XP_UNIX that compiles only in xpcom/io

it changes nsIFile and nsILocalFile to use AUTF8String strings.

and i created a hopefully shortlived interface nsILocalFileInternal for all of
the old string and wstring methods to ease the transition to UTF-8.
cc'ing some more folks who might want to comment on this...
this is fantastic. It is exactly what I wanted to see happen :)
The patch looks great from my initial scan.
Yeah. As far as the string params, looks good.

There's still some symlink following API issues discussed in bug 94323 but this
string param work is the biggest fish to fry.
actually darin it seems like your patch belongs in bug 129279.. a mere
technicality :)

Also, one thing in the patch - can you make the "Native" versions of each
function [noscript] just so people won't be tempted, since string wasn't meant
to handle non-ascii? 

The nice thing about this patch is that JavaScript probably won't need any
changes, since as long as the attribute names stay the same, JS will simply
start using the UTF8 attribute instead! You'll probably fix a few bugs related
to that just by fixing this..
Keywords: topembedembed, topembed-
Comment on attachment 74880 [details] [diff] [review]
attempt 4 using Nav4.7

obsoleting patch which was checked in so this doesn't look like an approved
change that is still not landed.
Attachment #74880 - Attachment is obsolete: true
marked nsIFile and nsILocalFile as frozen on the trunk and branch ;-)
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
Whiteboard: [fixed trunk]
You need to log in before you can comment on or make changes to this bug.