I would disagree. If we consider a component like "Address book" , there are bugs that cover all ranges, namely there are some hardcore bugs, some good first cpp bugs, some patchmaker bugs, some XUL bugs.
Ok, granted. We have some rather overbroad components in Mozilla.
The good thing about wiki's are they are easily updated, so I think it would be good for a kind of catalog pages of the documentation. It would be quick to make ad-hoc overview pages.
Write up some ad-hoc overview pages, and I'll check them in. If that's all we want it for, it's not worth the trouble of setting up a wiki.
Well, lets start by getting the list, then lets sort it and put it in categories.
find . -name "*.idl" -o \( \( -name "mailnews" -o -name "dom" -o -name "editor" \) -prune \) | grep idl
Are you saying that all such API's are defined in the IDL files, if that is the case I might give it a try..
All apis that are not internal to a module are defined in IDL files, basically... (there are some exceptions like unicode converters, and I think we should consider fixing those....)
Are actual API should really be some sort of extract of the IDL files, like doxygen, javadoc or the like.
Exactly. Most of the IDL files are incredibly poorly documented, though. And a lot don't clearly say what the thing does and how you would use it.
None should really say how you get one, since that's not part of the API.
I was perhaps assuming that the content was somehow structured so that one could overcome it by looking at a minority of subfolders.Maybe it was a bad assumption..
It's very loosely structured, really.... Content is all over and just linked to from a central spot (in theory).
-Boris _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
