[Mono-docs-list] Proposing a new documentation subsystem
Mario Sopena Novales
mario.sopena at gmail.com
Tue Dec 4 12:33:02 EST 2007
Jon replies are exactly what I meant. Nothing to add here.
By the way, your changes about adding AssemblyInfo to every members
sounds good to me. The only problem I see is what to do with the
already <since> tag that we have. Does the implementation collide in
On 03/12/2007, Jonathan Pryor <jonpryor at vt.edu> wrote:
> On Mon, 2007-12-03 at 15:26 -0500, Miguel de Icaza wrote:
> > > I spoke with Lluis Sanchez about using Mono.Addins to extend the
> > > documentation system and it seems a good approach because we will get
> > > all the subsytem for documentation updates and managment (both for
> > > providers and for doc sources) for free.
> > >
> > > This will enable downloading new docs or providers without updating
> > > the whole monodoc system. We can also get rid of the several xml files
> > > needed to finally reach the documentation files and free monodoc
> > > subsytem of some managment code.
> > Which kind of add-ins do you have in mind?
> I think he was suggesting that we bundle the XML docs *as* an add-in.
> (At least, this was my interpretation, and made me go "Cool!") This
> would allow using the existing Mono.Addins infrastructure to update the
> documentation after installation time.
> So no format changes (beyond what I've already proposed), just a
> distribution model change.
> This sounds rational to me.
> > Supporting downloading updates is a pipeline issue more than an "add-in"
> > issue. Sure, you can write an add-in, but the fundamental issues are:
> > * Someone needs to write the new docs (these happen at glacial
> > speeds)
> If we use add-ins as the package model and not the file format, this is
> a non-issue -- we use the existing docs, and write a program to compile
> the current (.source .tree .zip) file tuple into an add-in.
> > * If the above were fixed (hundreds of new docs per day),
> > updating docs should just be part to the core Monodoc
> > functionality.
> Exactly, but Mono.Addins already has updating as a core part of its
> functionality, so using Mono.Addins as the *distribution* format would
> allow code reuse here.
> - Jon
More information about the Mono-docs-list