[Mono-docs-list] Mono Documentation.

[Miguel de Icaza]

Hello,

   We should be thinking along the lines of who are we targeting with
this documentation?   I think there are two groups of people:

	* Users of Mono technologies as a ready-to-use product.

	* Developers of Mono components.

   The first group in the long run will probably consist of 95% of the
user base, while the later will remain a small percentage. 

   If you are embarking into writing documentation, it would be
beneficial to focus on the largest group: the users of mono
technologies.  With this in mind, I will reply to Alejandro's
suggestions" 

> 1. Adding extensions to our programs embedding Mono.
> 	1.1. With C.
> 	1.2. With Perl.

C is an interesting case, because many people will be embedding Mono
into C.

The particular case of Perl (and other languages soon to come) I think
is focused on Paolo's simple embedding of the Mono runtime with C that
allows Perl to call into Mono and viceversa.

Documenting this is aimed at a smaller group of people.  I think that
language embedding/merging/gating is probably best document in the
module itself, which is a more natural place to document it and track
it.

> 2. Mono LOGO.
> 3. Mono-guile.

These should probably be documented on their own as well.  When they are
mature, it would make sense to have a `users' guide scenario just as an
introduction and point to the right manual.

MonoLOGO is a full compiler implementation, while Mono-Guile is a
bridge, like the Perl bridge.  Probably bridges should be documented on
their own as well. 

> 4. Mono Debugger Framework (MDF)
> 	4.1. Backends.
> 	4.2. Frontends.

The debugger should be documented not from the perspective of a the
developers of it, but from the perspective of those that will be using
it.  Hence, both Backends and Frontends are implementation details,
which are of limited use to the general public.  There is enough
documentation in text format in the module for people interested in the
design.

Miguel