we can handle this mapping mechanism in a way that doesn't expose nsIProperties.

What I'd like to do is create a client usable iface to nsIDirectoryService. Right now, you get the service, QI it to nsIProperties and then use nsIProperties::Get() to get a file location. Directory service can use nsIProperties internally, but it should provide location getting, defining, and undefining methods itself. Another benefit of this is that, with a specialized "get" method, a "createIfDoesntExist" param could be added. The lack of which creates a bunch of redundant stat'ing now.

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

don't move bugs that are in the 1.0 dependency tree. sorry.

change qa contact to Ashish.

Since nsIDirectoryService is frozen, not much that can be done now. We'd have to define an nsIDirectoryService2 to make this happen. Since we can do that later, moving off 1.0 radar.

huh? nsIDirectotryService derives from nsIProperties by design! This should be WONTFIX. I would be very interested in the rationale discussed at this api review which concluded with this bug.

nsIProperties is frozen. nsIDirectoryService is frozen. The contract id defined allows that there be a successful QI from the directory service to the properties interface. marking WONTFIX.