[Mono-docs-list] Long term Monodoc feature requests.

[Todd Berman]

I have a couple longer term feature requests for Monodoc, some of which 
I might be interested in implementing, but all that I would like 
feedback on.

1) Make the zip files smaller. Right now it can take almost an hour to 
build the classdoc zip file for the main docs on my machine which is 
pretty painful. It seems to take forever because of the raw size of the 
material. If this zip file was split into zip files by namespace, or zip 
files by assembly, I think it would be a far faster update process. This 
change should be hidden from monodoc.dll consumers (the browser, 
MonoDevelop, and the web frontend).

2) Register docs not through the main monodoc module. Monodoc has 
wonderful editing facilities, useful for .net projects outside of just 
mono + gtk-sharp. If it were easy/possible to register zip files in a 
way other than through the one .xml file, that would make it far easier. 
As it stands even now, the debugger puts docs into place that monodoc 
wont load for some reason. We could even potentially remove the need for 
the xml file and have some special file put into the .zip file that 
monodoc looks for to identify why sort of provider to use. This is 
another change that should be hidden from the various monodoc.dll consumers.

3) Sharing gui. MonoDevelop (and potentially later others) are 
integrating with monodoc already, and the need to rewrite all the gui 
that monodoc has seems kinda backwards. It would be nice if there was a 
way of using the gui in the monodoc browser in other places, that would 
make things like history, the index, etc, a lot easier to deal with for 
tools trying to use monodoc.

4) Split the modules up. Right now the monodoc module in cvs is a beast. 
It would make a lot more sense to have 2 (potentially 3) different 
modules. The first would be monodoc-tools which would contain 
monodoc.dll, the assembler, etc, and most likely the current doc stuff. 
The second would be just the monodoc gui frontend(s). The potential 
third would be the web based frontend. This would be wonderful for stuff 
like gtk-sharp, as it would allow gtk-sharp to dep optionally on the 
monodoc-tools module/release and build its own docs the right way.

5) Integrate with either Lucene.Net or beagle to provide searching. This 
one basically speaks for itself :).

I know some of these are very big and very much long term, but it would 
be great to get some feedback going.

--Todd