> than one C-API call. To get an idea, install Tcl and make:
>
> man Tcl_FSStat
>
> and you will see that the *entire* Tcl-VFS API is documented in
> one single man-page.
ok, see. would be handy.
> Wiki seems very nice for collaborative work but I do not
> know if there is a wiki->doctools converter (doctools->wiki there is).
> If we start hacking wiki, how would you convert this into some
> other format?
Depends on what we need for doctools, or generally for documentation.
Example:
All Headings like NAME,SYNOPSIS,DESCRIPTION,EXAMPLES,SEE ALSO,KEYWORDS are
representated the same in the wiki, e.g. a third-level-heading:
=== SEE ALSO ===
Other "markup" like bold or underline is also easy parseable ('''bold''').
"Examples" start with one or more whitespace on a line.
So I think it should be very easy to hack a convert, as the structure is
always the same. Like this stupid hack:
http://naviserver.sourceforge.net/wiki/index.php/News2wiki.tcl
But, as the devil is in the details, maybe you send me a doctool-document in
the form that you can imagine as a template for NaviServer, and I take a look
at how complex it is to write a small converter script.
> The AS project started this and I do not see any moves
> there. The wiki-entered stuff is still there and nobody cares to
> get it into the CVS or get it translated to other off-line reading
> (man, html, pdf, etc) ?
Thats true. I think the effort stopped at the very beginning or halfway. But
if only we had it in the Wiki! The problem is that writing documentation
sucks, not writing the converter :-)))
> Who does which page? This is a simple matter of communication.
> I do not think that we need to divide this somehow. We are just
> a few people and it suffices to document as we go. I do not think
> that we will have much problems with that. A short email on the
> list telling: hey, I'j now do the ns_XZY or Ns_XZY() would do.
Ok. But we should have a complete list for C and TCL to know whats missing or
when we are finished.
I started with TCL, but the list is not perfect:
http://naviserver.sourceforge.net/wiki/index.php/Examples:Commands
> I think that tagging the CVS now with 4.99.0 is perfectly OK as it would
> identify a body in CVS which is fixed and against which we can file
> bugs.
Ok, so we tag it after the macro insertion (or whatever solution) for the
range headers?
> I would do the 5.0 after we've done all those nice new things like VFS
> support (advancing well, btw), fancier upload caps, integration of
> ns_cache,
> full support for byte-ranges, finalized docs etc. I would target this
> towards the end of the year.
ok.
