[Mono-docs-list] Long term Monodoc feature requests.
Wed, 09 Jun 2004 20:27:05 -0400
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
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.