I’m hitting a conceptual problem in Verbosio’s development. Say the user is editing a XUL document, one sprinkled throughout with URL’s: scripts, overlays, DTD’s, stylesheets, you name it. Most of these point to files which presumably don’t exist yet (for example,
I have at the moment four ideas, none of them very nice:
Basically, I feed it the content-type, then a comma, then the contents of the string as the second argument. The two disadvantages I know of are (a) URI’s are supposed to be short, and data: might be abusing that, and (b) data: URI’s don’t support hash targets (#foo). That means they’re useless for pointing within the document to a specific ID attribute (XBL depends on that pretty heavily, and (X)HTML likes it).
This means saving the file in a cached form to the local file system. This is probably the simplest, but it involves reading and writing to the file system repeatedly. (Every time the user changes to the document or a file depending on it, most likely.) It also doesn’t allow for granting chrome privileges that easily (though I suppose I could set CAPS security policies as needed). In case you’re wondering, this is %APPDATA%/(appName) in Windows, not …/dist/bin/anything.
This would mean creating a bunch of XPCOM components, starting with protocol handlers and channels. This is unfamiliar ground for me, but it would run fast and not abuse the system.
Hack the system to attempt reading from a JS source first.
Something like this is very likely to destabilize the GRE running this chrome application, and would probably involve a lot of the same work as the previous idea. It’s just not feasible.
I really, really need some help here. If left to my own devices, I will go with the second route. I would welcome implementations, except for the data: system. I’d also welcome other ideas to solving this problem.