Open Bug 433295 Opened 16 years ago Updated 2 years ago

Make prio.h constants easier to access from JS

Categories

(Core :: XPCOM, enhancement)

x86
Windows XP
enhancement

Tracking

()

People

(Reporter: johnjbarton, Unassigned)

References

Details

Attachments

(1 file)

If you read 
http://developer.mozilla.org/en/docs/Code_snippets:File_I/O
you'll see a table including various obscure values like PR_RDONLY. These values are in a header file prio.h, not useful for Javascript. These value have to be used in all kinds of file operations. Because the constants are not available in interfaces, folks write code with octal constants, which looks cool and retro and all that, but is a big waste of time for people who come later to maintain or reuse the code.

Or people use the constants even if they are not defined, as for example, nsIZipWriter, http://developer.mozilla.org/en/docs/nsIZipWriter, see the bottom example code.

Or people recode the constants over and over and over again, see for example
http://mxr.mozilla.org/mozilla/source/modules/libjar/zipwriter/test/unit/head_zipwriter.js
Did they copy them correctly? Just more lines of code to test.


The values seem to be
612 /* Open flags */
613 #define PR_RDONLY       0x01
614 #define PR_WRONLY       0x02
615 #define PR_RDWR         0x04
616 #define PR_CREATE_FILE  0x08
617 #define PR_APPEND       0x10
618 #define PR_TRUNCATE     0x20
619 #define PR_SYNC         0x40
620 #define PR_EXCL         0x80
Product: Firefox → Core
QA Contact: general → general
I'm not sure that nsIFile is the right place for them, since they're related to IO rather than attributes of a file. Perhaps they'd be better suited on one of the stream interfaces?
Component: General → XPCOM
QA Contact: general → xpcom
Summary: Define the prio.h constants in nsIFile → Make prio.h constants easier to access from JS
They could be replicated at the highest points in the type tree where they are used, including nsIFile.  
Now octal literals are deprecated, this would be really helpful.
(In reply to comment #3)
> Now octal literals are deprecated, this would be really helpful.

Sorry, I was talking about permissions and not flags, but this seems to be the same problem.
Blocks: 757351
I am trying to handle I/O errors during the saving of an attachment of a message
in thunderbird.

I just realized that in the whole operation of thunderbird, saving an attachment to native file system is one of the few places (maybe only?)
in TB where the user (and TB) needs to deal with 
the native platform's file system directly, and handle the I/O error encountered during the operation gracefully and the nature of such error
needs to be propagated to the user for subsequent handling.
("Aha, I forgot to disable write-protection on the USB memory stick" is one example.)

In other operations, TB can deal with abstracted upper-level objects such as
e-mail message, e-mail folder, and remote mail servers that talk protocols defined by RFCs, etc. (Only messy GUI to show the message in intelligible manner to the user and to let user compose e-mail message are outside the scope of RFCs, and the saving of an attachment of operation is one of such activities.)

Anyway, in trying to handle the I/O errors and to show the error encountered in an information-preserving manner so that the user can take a proper action,
I was made aware that the basic I/O error codes and other information that are
available in C/C++ side of the source code are not available to JavaScript at all (!)

So I searched bugzilla and came to this article.

So my understanding of the discussion here is that
we should put something like in the attachment to a system-wide visible
file, correct?

What file should that be?

We have waited far too long for this to happen, haven't we?

TIA
Attachment #821474 - Flags: feedback?(johnjbarton)
Hmm, this type of requests have been very popular everywhere, I suppose.
I just found out
Bug 757351 - Sync uses deprecated octal literals
which discusses the following:
https://developer.mozilla.org/en-US/docs/JavaScript_OS.Constants

It seems there are duplicate efforts everywhere :-(
Oh well.

Perfect is the enemy of good. I think we better publicize a few such solutions and see
what would be better (not the perfect choice).

To be honest, I have no idea what is the right solution for
say, the use of such symbolic values in,
Bug 928725 - Use of octal number is deprecated (JavaScript/ECMAScript) and so do not used it in xpcshell-tests files. 

TIA

PS: whichever file that catches the best attention among the developers would be useful...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.