183895 - Implement [nsIProperties.getKeys] for the profile directory service

Status: RESOLVED INVALID

(Core Graveyard :: Profile: BackEnd, enhancement)

Description

[timeless]

I use xpcshell to do my analysis of stuff and this feature would help me.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 183897 has been marked as a duplicate of this bug. ***

Comment 2

[Conrad Carlen (not reading bugmail)]

The profile directory service is only a provider, i.e., it implements
nsIDirectoryServiceProvider, not nsIProperties.

If you're asking for what I think you are:
* Implement nsDirectoryService::GetKeys().
In order to make that work:
* Have a means for directory service to get a list of keys from each of its
registered providers. Oh no! Here comes nsIDirectoryServiceProvider3 :-(

Comment 3

[timeless]

yeah, it took me a long time to figure that out.

I think we could cheat. if all directory providers implemented
nsIProperties::getKeys and returned error_not_supported or something for the
other nsIProperties methods that should be good enough.

the directoryservice would of course QI each provider to nsIProperties and use
that. it think it'd even be possible to handle moving from nsIProperties to
nsIDirectoryServiceProvider3 at a later time.

But this is really the price you pay for not having a good api design up front,
freezing early and often ;-(.

I'm certainly open to ideas, but I don't want to see
nsIDirectoryServiceProvider9 next december...

Comment 4

[Doug Turner (:dougt)]

Timeless - there is no need for a lecture about api freezing.  

The point is we had a good API design that supported exactly the customers it
was designed to support and was truly extensible.  However, after we froze the
interface, people wanted to return sets of nsIFile's(nsIDirectoryService2). 
This new interface, i would agree was frozen quite quickly.

Regarding this bug, what your requesting goes against the whole point of the
directory service providers which is to allow lazy creation of nsIFile object.
ie. providers do not have to create the nsIFile object until it is requested. 
given this design, the nsDirectoryServcie implementation of
nsIProperties::GetKeys, should return the current KNOWN keys - no all possible keys.

dougt