[Mono-dev] Mono.Addins in Monodoc

[Mario Sopena Novales]

Hi,

On 18/12/2007, Miguel de Icaza <miguel at novell.com> wrote:
> Hello,
>
> > What's nice about using Mono.Addins for all this?
>
> I do not see the use of Mono.Addins actually solving any real
> documentation problems.
>
> The issues that I have with Monodoc today are:
>
>         * Some of the internals are bad (we have two lookup mechanisms,
>           one uses tree expressions, one uses custom-url expressions,
>           it would be nice to unify them).
I agree with that

>
>         * The tree was supposed to be compact, it is not, its too large,
>           but that we can live with.
>
>         * Editing in the ECMA provider is hard, but Mike has a plan for
>           that.
Is there any doc or something we could review?


>
>         * The current provider API is suboptimal (see first point), and
>           before we launch ourselves into a large task to have plugins,
>           I would like the interface to be cleaned up, and some of the
>           most horrid hacks to go away.
I think both thing (refactoring the monodoc engine and using
mono.addins) can live together because they deal with different parts
of monodoc. One deals with installing/getting/configuring
documentation packages/providers/etc.. while the other deals with how
the providers/sources/renderes work.


>
>         * The editor needs to be able to "lint" or check if a see cref
>           is invalid for example and issue a warning.
>
> Then there are the more fundamental issues:
>
>         * We have not yet upgraded everything to 2.0 apis.
>
>         * We do not have enough documentation, and in general, we do
>           not have a culture of people editing and maintaining the docs.
This is in some way (maybe not much, I dont have the numbers but just
an impression) affected by the fact that in monodoc is hard to see how
the contribution gets back to the contributor. The process is slow.
I mean, the user cannot install new documentation (only installing a
"new" monodoc and that is slow specially if it comes packaged in the
distro) and the process to review/approve/publish new doc is also
slow, making at the end that the contributor feels his contributions
gets lost in the limbo (well, at least, that was what I was told
several times). The way we have it now discourages contributions.
Maybe, by using addins, we can made new "docs" releases which the user
can install easily so we can speed up the process. Of course, we also
need to imrpove the "admin" tool to easy the contributions review.



Mario


>
>         * The contribution stuff works, but reviewing the docs for .NET-
>           APIs is time consuming because lots of people are cut-and-
>           pasting from MSDN, so I have to review every contribution and
>           sometimes I just ignore the contributions altogether and just
>           go for the easy stuff that I know is not copy-paste (Gtk#)
>
> Adopting Mono.Addins might have some technical advantages, but I think
> that overall it will get in the way of some required internal work that
> needs to take place before we start considering more features.
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>