Closed Bug 14949 Opened 21 years ago Closed 20 years ago
[FEATURE] Need to support load() in chrome contexts
hmm. maybe brendan can add a few cents worth here.
It is up to the embedding to interpret the 'path' and know how (or if) to load the code. Is this just expected to be the equivelent of '#include' at script compile time or is it also expected to conditionally load script source as the code is running? The latter is a bigger task with more implications. This seems like a new class of things to plugin for the embedding. Also. If it *is* dynamic then it ought to hang off of some existing object rather than be a top level function. No? Nevertheless, I think that if this is a static #include then it needs to be a compiletime feature of the engine with 'plugin' support in the embedding. But if it is dynamic then it ought to be a feature of some embedding object only.
No JS preprocessors, if you please! This goes against years of ECMA and other grains. So load is a native method (of the global object, or some other object; TBD). It can be condition by an if and iterated using for, while, or do-while. Uh oh: now you need to suspend the executing script until the inner .js file has been read. That requires a thread, or the equivalent to capture the state of the JS engine and restore it later (said state being often on the machine stack as well as in interpreter data structures). This is looking hard without multi-threaded layout. The preprocessor idea looks better and better if you avoid making it "in-band": use XUL tags or processing instructions to compose your JS. Or, can we say that all load-able files are local files, and therefore fast to read? Even then, necko uses an asynchronous i/o model with worker threads doing the blocking reads. A "fast, synchronous" load method would have to do its own blocking reads, given an open descriptor for the local file. /be
Brendan, could you forward this bug to some appropriate person?
I'll trade you for that xpcdl bug. /be
Need to consider for architecture completeness, so marking M12. /be
Wait till the reporter is here to help me do it. /be
Pushing out till we have enough time to do this right. /be
Not likely till I get back from sabbatical. Anyone with inspiration, feel free to take this away from me. /be
Target Milestone: M14 → M16
Setting all Javacript bugs to rginda QA Contact.
QA Contact: cbegle → rginda
Adding 'skins' keyword to selected chrome bugs. Please add any omissions. Sorry for any mistakes...
Peter, is this really blocking 29160 (and if so, how)? Hyatt doesn't think this bug should be 'skins'. /be
Mass-adding beta2 keyword to all skins bugs.
Okay, my mistake, thanks for pointing it out. removing skins & beta2 keywords.
...and removing blocks
No longer blocks: 29160
OK, well, if we restrict loadable files to local ones, and we care only about XUL in chrome, then this bug asks for something already possible: var f = Components.classes['component://netscape/filespec'].createInstance() f = f.QueryInterface(Components.interfaces.nsIFileSpec); f.unixStyleFilePath = "extra.js"; eval(f.fileContents); Now I know we're not supposed to use nsIFileSpec any more, but I don't see any way to get data from JS out of an nsILocalFile or an nsFile. There should be a contents attribute, at least. Shaver and dougt, help me out! I'm going to mark this bug works for me (seems better than wontfix), and ask that Ben or anyone who finds a problem using the XPCOM file interfaces from JS, in conjunction with eval, to file specific new bugs on those XPCOM interfaces and/or their impls. Thanks, /be
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Adding dougt so he can check out the back-story recorded here. /be
> f.unixStyleFilePath = "extra.js"; Isn't that dependent on some particular current working directory or something equally unpredictable. While it may be possible to do something like this, it is a poor substitute for a even a minimal JS library loading mechanism. Do we really want to encourage this? Adding mccabe 'cuz I've been trying to get him excited about doing work to support some sort of JS package scheme for the pre JS 2.0 engine we have.
you can get to the contents of a file via necko. Also, Pete Colins has been working on a File I/O package. You can check out: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5695 This should give you a general idea of how to do this.
You need to log in before you can comment on or make changes to this bug.