[Mono-docs-list] feature suggestion

[Gustavo Ramos]

Hello Chris,

comments inline.

> I think I see how I've confused the matter a little for myself.  My 
> initial interest in Mono and related technologies started with trying to 
> develop asp.net type applications using mono + postgres.  I've read/ing 
> many books on c#, ado.net, components etc... just about anything I can 
> get my hands on really.  One of my complaints is that I can't find a 
> book now that has real and good examples.  I want to build custom asp 
> components but just reading the api is kinda dry (I find).  It is 
> helpful and necessary of course but it's even more interesting reading 
> the source code of how mono does it.  In this/my example, everything in 

Of course, it's better an image than thousand words. The source code is
like that, like an image: You see the engine working.

> asp.net is a component.  Component writing it's not a trivial task but 
> it's not like writing a new language from scratch.  I wasn't suggesting 
> to actually "write" anything or at least not too much.  Ideally there 

I misinterpreted this... okay, now got the point.

> would be a way to marry the current docs and the current source code. 
> Perhaps as an option of the MonoDoc to specify where you have the source 
> code installed and dynamically point to it from each class, delegate 
> etc... api spec.  If you don't specify it you don't get the link to the 
> source kind of thing. Maybe I'm being naive - but in my (narrow?) view 

I see more clearly your point. Then it shouldn't be too hard to
implement it.

>   Perhaps using a new custom attribute(s).  I would definitely volunteer 
> some time to do grunt work.  Some areas of the source code may be a 
> little scary [to some] but I'm sure if you are studying how to write an 
> ado.net provider or even how to use one better you wouldn't find it so 
> awful.  And you wouldn't have to read a book to gain that immediate 
> benefit.

I agree with you. You can learn a lot debugging an unknown piece of
software, you'll quickly become familiar with it. However, I see that we
are thinking about different things. Your point of view points out the
need of a cross-reference for the source code, and definitely would be
good --unvaluable for middle-advanced development--. Such a tool would
be an accelerator for better applications, well integrated, fine tuned
for mono.

The book I were talking about should serve for a different purpose: To
teach how the whole thing works. That, in practice, would be like
pulling a lot of developers that find scary *the whole thing*, like
training them to hack on it, and that would definitely improve greatly
the development of mono, and not so much of the applications.


Well, it should be great to know about both (or just one). Good idea Chris,


Gustavo