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.

nsIDirectoryService is frozen. adjusting summary

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

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

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

new file name is nsDirectoryServiceUtils.h

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

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

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

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

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

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.

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