99160 - Freeze nsIFile

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Doug Turner (:dougt)]

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.

Comment 1

[Doug Turner (:dougt)]

nsIDirectoryService is frozen.  adjusting summary

Comment 2

[Doug Turner (:dougt)]

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 [e-mail], or better yet,
use the tracking bug:

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

Comment 3

[Mark Follett]

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.

Comment 4

[Doug Turner (:dougt)]

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.  

Comment 5

[Doug Turner (:dougt)]

Attachment: Moves utility function into header file

As Mark mentioned, this needs to happen before the interface is frozen.

Comment 6

[rpotts (gone)]

Comment on attachment 74847 [details] [diff] [review]
Moves utility function into header file

sr=[e-mail]

Comment 7

[John Bandhauer]

Comment on attachment 74847 [details] [diff] [review]
Moves utility function into header file

r=jband

Comment 8

[Brendan Eich [:brendan]]

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

Comment 9

[Doug Turner (:dougt)]

Attachment: patch v.2

new file name is nsDirectoryServiceUtils.h

Comment 10

[Brendan Eich [:brendan]]

Those patches look the same to me, and to diff. :-)

/be

Comment 11

[Doug Turner (:dougt)]

Attachment: attempt 2 of patch v.2

Comment 12

[Doug Turner (:dougt)]

Attachment: attempt 3

I think we have a problem if this does not work!

Comment 13

[Doug Turner (:dougt)]

Attachment: attempt 4 using Nav4.7

There is a problem with 0.99.  I could not get the file://path_to_patch/patch
to notice my changes.

Comment 14

[Brendan Eich [:brendan]]

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

Comment 15

[Darin Fisher]

dougt: make sure jkeiser is aware of the problem you were seeing... it may be
some side effect of the new form POST implementation.

Comment 16

[Doug Turner (:dougt)]

i tried to reproduce the problem but could not.  Thanks for pointing me at jkeiser.

Comment 17

[Doug Turner (:dougt)]

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

Comment 18

[Darin Fisher]

Attachment: preliminary XP_UNIX patch

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.

Comment 19

[Darin Fisher]

cc'ing some more folks who might want to comment on this...

Comment 20

[Alec Flett]

this is fantastic. It is exactly what I wanted to see happen :)
The patch looks great from my initial scan.

Comment 21

[Conrad Carlen (not reading bugmail)]

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.

Comment 22

[Alec Flett]

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..

Comment 23

[Asa Dotzler [:asa]]

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.

Comment 24

[Darin Fisher]

marked nsIFile and nsILocalFile as frozen on the trunk and branch ;-)