70349 - nsIProperties needs to be removed from the directory service

Status: RESOLVED WONTFIX

(Core Graveyard :: Embedding: APIs, defect)

Description

[Judson Valeski]

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

Comment 1

[Conrad Carlen (not reading bugmail)]

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.

Comment 2

[Michael Dunn]

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

Comment 3

[Asa Dotzler [:asa]]

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)

Comment 4

[Asa Dotzler [:asa]]

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

Comment 5

[David Epstein]

change qa contact to Ashish.

Comment 6

[Conrad Carlen (not reading bugmail)]

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.

Comment 7

[Doug Turner (:dougt)]

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.

Comment 8

[Doug Turner (:dougt)]

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.