Menu
▾
▴
naviserver-devel
|
From: Vlad S. <vl...@cr...> - 2006-09-04 20:30:15
|
Maybe instead of solving documentation issue technically using conversion tools we can just include html pages with all we have docs into distributon, like Apache does, once installed we will copy manuals under pages so every new install will have access to docs even without writing any script. Those docs can have working examples, simple ones or complex does not matter but they will perform testing and educational tasks at the same time. I went through AOlserver site, wiki and our wiki and pieces of docs, it is spread and having this simply as html docs in one place may be easier. Just a thought inspired by thread on AOLserver mailing list:-)) -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-09-04 20:43:55
|
I was looking at the docs too. I installed fedoras tcllib and there's a doctools lib, but no standalone tool to convert things. Should there be? Or where does this live? Also, how are folks converting the templates to man and html pages? I can't see any Makefile rules, in the Tcl thread package for example. Are people just converting by hand and putting the result in CVS? I dunno about the below -- docs live in /usr/shar/doc/naviserver-x.x... I'd like to make things more standard, not less. I see the docs in two parts, the man pages, which are a technical reference, and the HOWTO stuff. Seems to me like the technical ref should be kept uptodate with the code, and the HOWTO stuff on the wiki, where people can, hopefully, update it. Pointing people in the right direction is a good idea though. How about a default start page for the installed server which focusses more on what to do next, rather than advertising? Could point to the installed html version of the docs with a file:/// reference, and the online wiki for HOWTO stuff, talk about the reference config file, and the the stats module can be enabled for introspection stuff. The current index.adp in contrib doesn't mention any docs at all... Or how t osign up to the mailing list, or how to report a bug, or how to find modules to install... On 9/4/06, Vlad Seryakov <vl...@cr...> wrote: > > Maybe instead of solving documentation issue technically using > conversion tools we can just include html pages with all we have docs > into distributon, like Apache does, once installed we will copy manuals > under pages so every new install will have access to docs even without > writing any script. Those docs can have working examples, simple ones or > complex does not matter but they will perform testing and educational > tasks at the same time. > I went through AOlserver site, wiki and our wiki and pieces of docs, it > is spread and having this simply as html docs in one place may be easier. > > Just a thought inspired by thread on AOLserver mailing list:-)) > > -- > Vlad Seryakov > 571 262-8608 office > vl...@cr... > http://www.crystalballinc.com/vlad/ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Stephen D. <sd...@gm...> - 2006-09-04 20:48:22
|
On 9/4/06, Vlad Seryakov <vl...@cr...> wrote: > > Just a thought inspired by thread on AOLserver mailing list:-)) It must be that time of year again... :-) |
|
From: Vlad S. <vl...@cr...> - 2006-09-04 21:01:06
|
> I see the docs in two parts, the man pages, which are a technical > reference, and the HOWTO stuff. Seems to me like the technical ref > should be kept uptodate with the code, and the HOWTO stuff on the > wiki, where people can, hopefully, update it. Even technical pages, having them quickly on the same server you are working under /docs or /_docs or /whatever with search could be easier, i like man pages but cross referencing and quick access is not their best > Pointing people in the right direction is a good idea though. How > about a default start page for the installed server which focusses > more on what to do next, rather than advertising? Could point to the > installed html version of the docs with a file:/// reference, and the > online wiki for HOWTO stuff, talk about the reference config file, and > the the stats module can be enabled for introspection stuff. I do not see where to point now, too many pieces around, so i think about one repository for all docs, better under CVS so changes can be tracked and all docs easily retrievd by one cvs command. > The current index.adp in contrib doesn't mention any docs at all... > Or how t osign up to the mailing list, or how to report a bug, or how > to find modules to install... Agree, why stats module is password protected, we can change it to make no password for locahost at least. -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 13:01:20
|
On 04.09.2006, at 22:51, Vlad Seryakov wrote: > >> I see the docs in two parts, the man pages, which are a technical >> reference, and the HOWTO stuff. Seems to me like the technical ref >> should be kept uptodate with the code, and the HOWTO stuff on the >> wiki, where people can, hopefully, update it. > > Even technical pages, having them quickly on the same server you are > working under /docs or /_docs or /whatever with search could be > easier, > i like man pages but cross referencing and quick access is not > their best Allright: cross-referencing is of course miserable. But as I'm most of the time on command-line, a proper usage of 'apropos', 'man' and 'grep' solves 95 % of my needs. I never saw ANY other Tcl documentation (apart from very first book from JO). > >> Pointing people in the right direction is a good idea though. How >> about a default start page for the installed server which focusses >> more on what to do next, rather than advertising? Could point to the >> installed html version of the docs with a file:/// reference, and the >> online wiki for HOWTO stuff, talk about the reference config file, >> and >> the the stats module can be enabled for introspection stuff. > > I do not see where to point now, too many pieces around, so i think > about one repository for all docs, better under CVS so changes can be > tracked and all docs easily retrievd by one cvs command. This also speaks for centralized reference docs to which I agree. But the HOWTO's are best done under Wiki where others may add more salt. Zoran |
|
From: Bernd E. <eid...@we...> - 2006-09-05 07:31:01
|
> Maybe instead of solving documentation issue technically using > conversion tools we can just include html pages with all we have docs > into distributon, like Apache does, once installed we will copy manuals > under pages so every new install will have access to docs even without > writing any script. Those docs can have working examples, simple ones or > complex does not matter but they will perform testing and educational > tasks at the same time. > I went through AOlserver site, wiki and our wiki and pieces of docs, it > is spread and having this simply as html docs in one place may be easier. How do Apache folks do it? Is the base of documentation HTML? I would suggest some simple XML at least, so we are able to use the same tool (e.g. tdom) and mechanism (e.g. XSLT) for both man pages and the documentation Vlad suggested to put under docroot. Even the NEWS file could be compiled from the XML base, to not double work. Btw: Right now we use (ok, don't use) doctools and dtplite from tcllib. Would some readable XML feel more natural or would it lower the mental burden to start documenting? Using XML/XSLT would still allow to also create doctools format and then creating usual xyz-roff format. Most of the content on the Wiki is static. I would not vote against replacing it with static HTML content (about, license, news; links to SF) that mainly includes the transformed parts of the documentation base. Nothing is lost, the current activity is mainly removing hidden div-layers with SPAM links :-| Bernd. |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 12:57:52
|
On 04.09.2006, at 22:43, Stephen Deasey wrote: > I was looking at the docs too. I installed fedoras tcllib and there's > a doctools lib, but no standalone tool to convert things. Should > there be? Or where does this live? zvpb:~/meta/usr/local/aw/log zoran$ dtplite /usr/local/bin/dtplite wrong#args, expected: -o outputpath ?-merge? ?- ext ext? ?-style file? ?-header file? ?-footer file? ?-nav label url?... format inputpath This gets done if you "make install" the tcllib. > > Also, how are folks converting the templates to man and html pages? I > can't see any Makefile rules, in the Tcl thread package for example. > Are people just converting by hand and putting the result in CVS? The "folks" in the Tcl threading extension (i.e. myself) are not doing it from the makefile. I have a Tcl script doing the conversion and I hit that script once per hand before doing the distribution. A million$ question: why not over makefile? Answer: perhaps I'm lazy to write a makefile rule for that? > > I dunno about the below -- docs live in > /usr/shar/doc/naviserver-x.x... I'd like to make things more > standard, not less. > > I see the docs in two parts, the man pages, which are a technical > reference, and the HOWTO stuff. Seems to me like the technical ref > should be kept uptodate with the code, and the HOWTO stuff on the > wiki, where people can, hopefully, update it. Agree 100%. The technical reference should be preferably in form of man pages (I never look ANY Tcl docs except man-pages) and optionally in HTML for those bright young people arround (not including me). The HOWTO should be definitely a Wiki. But, it is the former where problems start. As it may be in several usable formats (nroff, perhaps man, perhaps pdf). > > Pointing people in the right direction is a good idea though. How > about a default start page for the installed server which focusses > more on what to do next, rather than advertising? Could point to the > installed html version of the docs with a file:/// reference, and the > online wiki for HOWTO stuff, talk about the reference config file, and > the the stats module can be enabled for introspection stuff. Nothing to object to. > > The current index.adp in contrib doesn't mention any docs at all... > Or how t osign up to the mailing list, or how to report a bug, or how > to find modules to install... Ditto... I believe the best way to do that is get somebody new use the code and tell him to document all that he/she finds odd or missing :-) We are (I am) far too much into it over the years and it looks all so "known" to me that I really have to motivate myself to write that "obvious" things. Zoran |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 13:09:23
|
On 05.09.2006, at 14:57, Zoran Vasiljevic wrote: > But, it is the former where problems start. As it may be in > several usable formats (nroff, perhaps man, perhaps pdf). I ment really: (nroff, perhaps html, perhaps pdf). |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 13:07:49
|
On 05.09.2006, at 09:34, Bernd Eidenschink wrote: > How do Apache folks do it? Is the base of documentation HTML? > I would suggest some simple XML at least, so we are able to use the > same tool > (e.g. tdom) and mechanism (e.g. XSLT) for both man pages and the > documentation Vlad suggested to put under docroot. Even the NEWS > file could > be compiled from the XML base, to not double work. AHHHHHH! XML again!? I wen't there and I came back! The first doc in threading extension was TMML (based on XML). It was a HORROR to maintain and I switched to tcllib instead. Had a look at POD (perl doc format pendant)? Well this is basically tcllib format. Easy to write and maintain. Sometimes when a page becomes pretty large, you can get lost, but in XML I get lost about 10 lines below. Same as HTML. You need a damn good tool to use it productively, especially when making large changes. > > Btw: Right now we use (ok, don't use) doctools and dtplite from > tcllib. Would > some readable XML feel more natural or would it lower the mental > burden to > start documenting? Using XML/XSLT would still allow to also create > doctools > format and then creating usual xyz-roff format. NO. MORE burden! Please lets forget XML before we write yet another line on that. To my opinion, the tcl doctools format is the simplest most natural to understand and write format I've come accross when writing short(er) man pages. And this is the bulk of that we need.... Cheers Zoran |
|
From: Bernd E. <b.e...@ki...> - 2006-09-05 14:24:55
|
> NO. MORE burden! > Please lets forget XML before we write yet another line on that. > > To my opinion, the tcl doctools format is the simplest most natural > to understand and write format I've come accross when writing short(er) > man pages. And this is the bulk of that we need.... Relax! I won't delete the src directory and replace it with XSLT scripts :-) I felt into the format-discussion-trap again, sorry. When using doctools we have various output formats available, nroff, html, tmml, latex, wiki (see src/README.doc). We can put stuff below docroot, into man/, on the wiki. The technical stuff and format is already there. The general problem is: We don't _want_ to write documentation. Not for man pages and not for the Wiki. If we make it a priority we can surely provide appropriate templates that everyone feels comfortable with. We just have to cut the Gordian knot. Bernd. |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 14:39:43
|
On 05.09.2006, at 16:28, Bernd Eidenschink wrote:
> The general problem is: We don't _want_ to write documentation. Not
> for man
> pages and not for the Wiki.
... so it is the attitude and not format that we're fighting with.
And given the low(est possible) attitude we need to make it as
simple as possible.
For long time I wanted to create a set of templates for each and
every ns_xxxxx command for somebody (even myself) to start adding
some content there. Because, without adding content to whatever
formated file, there will be no docs.
And by just lumping together all available html into one place,
you just "organize a disorder" creating even more disorder.
If we want to have documentation:
a. we should split techical ref from howto (as stephen correctly
pointed out)
(the b. to c. below handle only the former)
b. we whould employ some stupid and easy format everybody can
handle which
is capable of expressing enough formatting rules so we can get
a decent
looking nroff and/or html
c. we should start adding (by copying or writing new) content to
those templates.
Without b. and c. we will have no usable documentation!
I totally neglected the C-API so far as this is "roughly" collectable by
gathering function level comments for Ns_XXXX functions from C-sources.
OTOH, the Tcl API isn't.
Cheers
Zoran
|
|
From: Bernd E. <eid...@we...> - 2006-09-05 15:08:13
|
> ... so it is the attitude and not format that we're fighting with. > And given the low(est possible) attitude we need to make it as > simple as possible. correct! > b. we whould employ some stupid and easy format everybody can > handle which > is capable of expressing enough formatting rules so we can get > a decent > looking nroff and/or html > > c. we should start adding (by copying or writing new) content to > those templates. > > Without b. and c. we will have no usable documentation! if we have (b) we can organize (c). we would create (d) a list of what we want to document and volunteer for the commands we are able to document (as some brand new commands clearly belong to a certain developer. who is fast grabs the existing old ones and just updates them :-)). So, the next step is (b)... Bernd. |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 15:18:53
|
On 05.09.2006, at 17:12, Bernd Eidenschink wrote: > > So, the next step is (b)... If you look at the nsproxy directory, you will find a man-page written in doctools. You can use dtplite to translate it to html on nroff. And for the c. it is actualy writing a bare-bones template doctools file for each of the ns_xxx commands. This could be a 1/2 hour job and can be automated. The "tough" part remains though... EVERYBODY would need to contribute to adding content (either by stealing it or inventing it new). Zoran |
|
From: Vlad S. <vl...@cr...> - 2006-09-05 15:25:15
|
b. is doctools i suppose, format is simple enough and has many formats to convert. documenting commands is okay, but man pages are needed to those who already developing something and knows what to look for. Top level docs, like overviews, guides and manuals will make documentaion user friendly. I found in my hard drive old circa 2002 aolserver docs, including C-API, Tcl-API and other overviews. Not bad documentation and still apllies to naviserver as well. It is html already, converting it to doctool does not make sense but not using it does not make sense for me either. And correting these old docs is not that hard, the question is: where we put it? CVS? SF mane page? Wiki? For the problem where do i start: man pages or Wiki or another document, too many different ways and still it will be kept in pieces in different places. Bernd Eidenschink wrote: >> ... so it is the attitude and not format that we're fighting with. >> And given the low(est possible) attitude we need to make it as >> simple as possible. > > correct! > >> b. we whould employ some stupid and easy format everybody can >> handle which >> is capable of expressing enough formatting rules so we can get >> a decent >> looking nroff and/or html >> >> c. we should start adding (by copying or writing new) content to >> those templates. >> >> Without b. and c. we will have no usable documentation! > > if we have (b) we can organize (c). we would create (d) a list of what we want > to document and volunteer for the commands we are able to document (as some > brand new commands clearly belong to a certain developer. who is fast grabs > the existing old ones and just updates them :-)). > > So, the next step is (b)... > > Bernd. > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 15:36:06
|
On 05.09.2006, at 17:24, Vlad Seryakov wrote: > b. is doctools i suppose, format is simple enough and has many formats > to convert. I would wote for that. > > documenting commands is okay, but man pages are needed to those who > already developing something and knows what to look for. Top level > docs, > like overviews, guides and manuals will make documentaion user > friendly. Yes. This is what I'd do in Wiki. After all the Wikipeida does much more content that we'd do in 1000 lives, yet still all is done in Wiki (amazing, isn't it?). > I found in my hard drive old circa 2002 aolserver docs, including C- > API, > Tcl-API and other overviews. Not bad documentation and still > apllies to > naviserver as well. It is html already, converting it to doctool does > not make sense but not using it does not make sense for me either. And > correting these old docs is not that hard, the question is: where > we put > it? CVS? SF mane page? Wiki? Wiki. > > For the problem where do i start: man pages or Wiki or another > document, > too many different ways and still it will be kept in pieces in > different > places. Both :-) We (I'm afraid to say I) can start ref-doc immediately and never finish (i.e. we just add content as we *can*). The "bad" thing about the other (Wiki) is: it just takes lots of time! I personaly can add to the ref docs by filling in the man pages but I can't write top-level overview type of docs. I just have no time for that. OTOH, I would be more than happy if we just manage to get the Tcl API completely documented! Cheers Zoran |
|
From: Bernd E. <eid...@we...> - 2006-09-05 15:53:25
|
Two questions concerning the Wiki: 1. How are Backups done for the Wiki at the moment? Should more and more content be put to it, can we automate it (data from MySQL etc.) if not already done? 2. There is lot of discussion about limiting access to Wikis at the moment. Can we jump on the train and limit access to people that ask for it? I remove SPAM from time to time and it's annoying. I can't ignore the SPAM either, I'm Monk ;-) Bernd. |
|
From: Vlad S. <vl...@cr...> - 2006-09-05 15:49:55
|
> > Yes. This is what I'd do in Wiki. After all the Wikipeida does much more > content that we'd do in 1000 lives, yet still all is done in Wiki > (amazing, isn't it?). > >> I found in my hard drive old circa 2002 aolserver docs, including C- >> API, >> Tcl-API and other overviews. Not bad documentation and still >> apllies to >> naviserver as well. It is html already, converting it to doctool does >> not make sense but not using it does not make sense for me either. And >> correting these old docs is not that hard, the question is: where >> we put >> it? CVS? SF mane page? Wiki? > > Wiki. But how we can put existing docs into Wiki, i guess starting from the scratch is very frightening(at least for me) >> For the problem where do i start: man pages or Wiki or another >> document, >> too many different ways and still it will be kept in pieces in >> different >> places. > > Both :-) > We (I'm afraid to say I) can start ref-doc immediately and > never finish (i.e. we just add content as we *can*). > > The "bad" thing about the other (Wiki) is: it just takes > lots of time! I personaly can add to the ref docs by > filling in the man pages but I can't write top-level > overview type of docs. I just have no time for that. Yes, SF Wiki site is so slow, almost unusable, not even for developer but for regular users as well So, to do: 1) Making templates for all Tcl commands, i.e. creating .man files 2) Converting existing .n pages into .man files 3) Importing/collecting all existing docs about AS and NS 4) Create top level structure and put all docs there or links . . ... slowly adding stuff ... . Concerns: 1) SF Wiki, this is my big concern, slow, no way to easily correct, need to login, how to download original source to keep in CVS for example 2) I would like to generate Wiki from source files, from doctools, if we have all command as .man files, we can easily generate Wiki page similar to AS wiki on panoptic.com (BTW, this is good source of docs as well) -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Bernd E. <eid...@we...> - 2006-09-05 16:07:11
|
> Concerns: > > 1) SF Wiki, this is my big concern, slow, no way to easily correct, need > to login, how to download original source to keep in CVS for example > > 2) I would like to generate Wiki from source files, from doctools, if we > have all command as .man files, we can easily generate Wiki page similar > to AS wiki on panoptic.com (BTW, this is good source of docs as well) I don't think the Wiki is so good for storing the documentation, because people can and should add to it and change things at everytime. It's good for HowTos and things like that. Would you overwrite changes with the export? Or freeze the Wiki-doc and "port " changes into existing documentation source? Is there a way to import the dtplite-created wiki files into the wiki at all? (In a way links and references work)? I would vote for creating a simple bunch of HTML files from the doctools, place the HTML on the webspace and link to it from the Wiki. Bernd. |
|
From: Bernd E. <b.e...@ki...> - 2006-09-05 15:53:25
|
> If you look at the nsproxy directory, you will find a > man-page written in doctools. You can use dtplite to > translate it to html on nroff. yes, I know the file! you did a good example for adding a new command along with it's documentation. my first try with doctools was ns_sendmail command and an example for conversions (README.doc), found in doc/src/. > And for the c. it is actualy writing a bare-bones template > doctools file for each of the ns_xxx commands. This could > be a 1/2 hour job and can be automated. > > The "tough" part remains though... EVERYBODY would need to > contribute to adding content (either by stealing it or > inventing it new). of course. therefore my suggestion to make a list and ask who wants to grab what command. 1 per month per developer should be possible and next year, same time, we are nearly done :-) Bernd. |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 16:02:38
|
On 05.09.2006, at 17:41, Bernd Eidenschink wrote: > > of course. therefore my suggestion to make a list and ask who wants > to grab > what command. 1 per month per developer should be possible and next > year, > same time, we are nearly done :-) > If you ask me, I can push the average on about 4 commands per month (one each week roughly). With a proper self-discipline (I would not count on that) this can be elevated to perhaps a double (2 per week). If we count *active* commiters, this yields 4. 4 * 4 = 16 cmds per month and this is about 192 commands per year. Now: llength [info comman ns_*] 204 This means we've rougly finished in 1 year. This is totally realistic, provided EVERYBODY remains consistent on the average. As you are the Wiki expert (hehe) you can add a page with all this commands listed and everybody can edit this page writing his name next to command he's currently doing. This way I can pick-up a "orphan" command, put my name there and start to work w/o need to pickup list of commands in advance. Cheers Zoran |
|
From: Bernd E. <eid...@we...> - 2006-09-05 16:22:57
|
> As you are the Wiki expert (hehe) Oh, please don't call me that ;-) I really respect the whole Wiki thing for what it created (Wikipedia et al), but I don't like the technology. The surprising part for me is how much success a project can have if people don't need a password to contribute... > you can add a page with all > this commands listed and everybody can edit this page writing > his name next to command he's currently doing. This way I can > pick-up a "orphan" command, put my name there and start to work > w/o need to pickup list of commands in advance. A rough list: http://naviserver.sourceforge.net/wiki/index.php/Examples:Commands Bernd. |
|
From: Gustaf N. <ne...@wu...> - 2006-09-06 07:50:50
|
Bernd Eidenschink schrieb:
> I really respect the whole Wiki thing for what it created (Wikipedia et al),
> but I don't like the technology. The surprising part for me is how much
> success a project can have if people don't need a password to contribute...
>
maybe an option is to look at xowiki:
to address some of the items mentioned here so far:
- it is php-free
- implements various security policies (some pages can be made public
modifyable, others
are modifiably only for some developers)
- it has already some converters (e.g. from man format or from
doc-book generated HTML)
see the import/export section towards the end of the documentation
below)
- keeps versions in the content repository
- to add automatic conversion via dtplite should be straightworward
(keep revisions
of the dtplite sources in the content repository, generate html on
the fly)
- has full text search, categories, notifications, rss, glossary,
file/image support....
(some of these are inherited from openacs)
http://media.wu-wien.ac.at/download/xowiki-doc/
see it in action: http://openacs.org/xowiki/
available from the oacs cvs repository
-gustaf
|
|
From: Vlad S. <vl...@cr...> - 2006-09-05 16:23:11
|
Also, AS wiki already has documented almost every command, so we can shamelessly borrow from there and import to our docs with corrections. Zoran Vasiljevic wrote: > On 05.09.2006, at 17:41, Bernd Eidenschink wrote: > >> of course. therefore my suggestion to make a list and ask who wants >> to grab >> what command. 1 per month per developer should be possible and next >> year, >> same time, we are nearly done :-) >> > > If you ask me, I can push the average on about 4 commands per month > (one each week roughly). With a proper self-discipline (I would not > count on that) this can be elevated to perhaps a double (2 per week). > If we count *active* commiters, this yields 4. 4 * 4 = 16 cmds per > month and this is about 192 commands per year. > > Now: > > llength [info comman ns_*] > 204 > > This means we've rougly finished in 1 year. This is totally > realistic, provided EVERYBODY remains consistent on the average. > > As you are the Wiki expert (hehe) you can add a page with all > this commands listed and everybody can edit this page writing > his name next to command he's currently doing. This way I can > pick-up a "orphan" command, put my name there and start to work > w/o need to pickup list of commands in advance. > > Cheers > Zoran > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-05 16:34:12
|
On 05.09.2006, at 18:22, Vlad Seryakov wrote: > Also, AS wiki already has documented almost every command, so we can > shamelessly borrow from there and import to our docs with corrections. Allright. Be it then. So it is the proven cut/paste technology ;-) Too bad guys didn't invent a wiki->man converter! I wonder if it would make sense to write one... As the matter of fact this could be fairly easy task: cut the text from Wiki html page, paste into template. There you go! This way I can even achieve 4 commands per month effectively reducing our effort to about 1/2 year :-) Very nice. Cheers, Zoran |
|
From: Bernd E. <eid...@we...> - 2006-09-05 17:03:57
|
> Too bad guys didn't invent a wiki->man converter! I wonder if it > would make sense to write one... > > As the matter of fact this could be fairly easy task: > cut the text from Wiki html page, paste into template. > There you go! > This way I can even achieve 4 commands per month effectively > reducing our effort to about 1/2 year :-) http://wiki2man.sourceforge.net/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X