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 _______________________________________________ Mono-docs-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-docs-list
