On 3/3/06, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > Darin Fisher wrote: > > 1) You could use thread local storage (TLS) for the context parameter, > > and implement this today without any new APIs. > > How do I do this from an extension's JavaScript?
Well, there must be some API somewhere to get the right context parameter to pass to necko, right? > How do I do this if I'm > proxying my Necko access to the main thread from a background thread? Yes, good point. You'd have to do more than just call NewURI. You'd have to setup the security context and then call NewURI. Yeah, that wouldn't be very nice. Maybe we should extend the XPCOM proxy API to accept a security context that is "pushed" into place for the scope of the proxy call. > In any case, the point is to make it as hard as possible to screw up. Having > to > set a global (or thread-local) variable before making a newChannel call is > just > as bad as having to call CheckLoadURI, from that point of view, whereas just > knowing that any newChannel call is insecure and that there is a simple more > secure option might work better... I hope. So, this new API isn't useful unless a consumer knows how to get a context in the first place. Maybe it would help me to understand where that comes from. > > 2) Why not use nsIProtocolHandler::protocolFlags to convey capability > > requirements? > > We might be able to get away with that, yes. At the moment, I just need to > differentiate between a small finite set of options (like 3-4). If you're ok > with giving me a few bits to work with, I could probably put something > together... Yes, this is something that I have always envisioned using those flags for. There are plenty of available bits. -Darin _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
