You are viewing a plain text version of this content. The canonical link for it is here.
Posted to websh-dev@tcl.apache.org by Ronnie Brunner <ro...@netcetera.ch> on 2002/04/02 17:58:26 UTC
Status development websh3.5 and documentation
We're somehow behind schedule: we planned a release by end of last
month. I would appreciate, if we could concentrate on the important
stuf now, so the effort we put into the project actually gets us
somewhere.
- Are there any code issues that still need to be looked at?
- What's the status of the web site migration?
- The documentation still sucks (oops, xcuse my language)
Imho we need to put most of the effort into the documentation. A few
suggestions and issues that came up when I looked at quickref.xml
today:
- the commands are not consistently documented (e.g. web::tempfile
does not have a syntax)
- The contents is very un-readable. A few suggestions (just as a
discussion basis):
- Split Command dispatching and session management into two chapters
- *Only* have the commands as subchapters (except for the
introduction chapter) I don't know if that scales, but I'd like to
have a cleaner Contents section
- This would actually imply that the examples have to be moved
somehow (either create an examples section at the end and link the
different chapters to the examples)
- Move the general description stuff to the beginning of the
respective section (e.g. in the Command dispatching section the
stuff about the cmdurlcfg)
I know that I haven't the cool solution either, but we definitly
have to improve the documentation not just on the content side, but
also on the formal side.
- Documentation is not uptodate. e.g. web::cmdurlcfg still describes
the -protocol option
-> we HAVE to really look at every command in detail and check the
documentation for accuracy. And I don't see a different way than
splitting up [info commands web::*] and assign a couple of commands
to everyone willing to spend a couple of hours.
Opinions?
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: Status development websh3.5 and documentation
Posted by "David N. Welton" <da...@dedasys.com>.
davidw@dedasys.com (David N. Welton) writes:
> Ronnie Brunner <ro...@netcetera.ch> writes:
>
> > What are the paths we need to provide?
>
> > - server root (env(SERVER_ROOT) if it exists in CGI case, "" otherwise)
> > - document root (env(DOCUMENT_ROOT) if it exiss in CGI case, "" otherwise)
> > - mod_websh config dir/file ("" in CGI case)
> > - interpclass path (path of CGI-executable == [pwd] in CGI case)
> > - actual path to script requested (SCRIPT_FILENAME or PATH_TRANSLATED
> > or something ...)
On second thought, maybe just using web::request with these is best.
I have an email in to dev@httpd.apache.org, to see if they have any
better ideas. It is a bit unpleasant not being able to ever chdir to
someplace.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: Status development websh3.5 and documentation
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> What are the paths we need to provide?
> - server root (env(SERVER_ROOT) if it exists in CGI case, "" otherwise)
> - document root (env(DOCUMENT_ROOT) if it exiss in CGI case, "" otherwise)
> - mod_websh config dir/file ("" in CGI case)
> - interpclass path (path of CGI-executable == [pwd] in CGI case)
> - actual path to script requested (SCRIPT_FILENAME or PATH_TRANSLATED
> or something ...)
The thing I don't like about this is that we don't use 'env' for other
things. Like HTTPS, for instance... I think we should be consistent,
and provide either a command or a tcl variable.
> > > - The documentation still sucks (oops, xcuse my language)
> > I agree, but there's a lot of it:-( I've spent a lot of hours
> > wading through it, and it seems like it never ends...
> Don't tell me, I know what it is like :-( But we still need to
> improve. Suggestions on how to divide the work?
Well, I think I'm close to having the structural changes done. At
that point, we should at least have something we can work with as far
as the information contained being done up right.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: Status development websh3.5 and documentation
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> Yes - we need a way to get the location of the script for mod_websh
> stuff. We also need to fix the session stuff, along with a few
> makefile tweaks, maybe.
we started about this earlier. The last ideas were:
> > > > So we might have to provide these accessors already. How about
> > > > some additions to web::config such as serverdir (Apache
> > > > ServerRoot), documentroot (Apache DocumentRoot), pooldir
> > > > (directory of current interppool), confdir (Apache WebshConfig)
> > > > Does that make sense?
> > > Yes... but... won't this introduce a split between mod_websh
> > > powered app's and CGI apps? I think the cwd should be where the
> > > file is located, but I'm not sure how to work around the threading
> > > problem, and am currently investigating.
> > I wouldn't mind having websh just return an empty string in the CGI
> > case for the unknown paths. Actually: some servers (e.g. Apache ;-)
> > do put these paths into the CGI environment, so we could try to
> > access them from the environment within websh3: DOCUMENT_ROOT,
> > SERVER_ROOT, [file dirname $env(SCRIPT_FILENAME)] ...
> Environmental variables aren't used elsewhere in WebSH, even when they
> are made available through the server. I don't think we should make
> an exception just for this.
We do use the env variable in the CGI case: setting up the request
structure, we eval web::cgi::copyenv from script.ws3, which does
exactly that (there is no other way to get that info in a CGI)
-> I would still opt for a solution that just that provides an
accessor for these paths. Is web::config really the place? Although
it's also in the environment in the CGI case, I wouldn't mix it up
with the request info (because it isn't request info, and because we
get potential name clashes when we introduce our own variables).
What are the paths we need to provide?
- server root (env(SERVER_ROOT) if it exists in CGI case, "" otherwise)
- document root (env(DOCUMENT_ROOT) if it exiss in CGI case, "" otherwise)
- mod_websh config dir/file ("" in CGI case)
- interpclass path (path of CGI-executable == [pwd] in CGI case)
- actual path to script requested (SCRIPT_FILENAME or PATH_TRANSLATED
or something ...)
> > - The documentation still sucks (oops, xcuse my language)
>
> I agree, but there's a lot of it:-( I've spent a lot of hours wading
> through it, and it seems like it never ends...
Don't tell me, I know what it is like :-( But we still need to
improve. Suggestions on how to divide the work?
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: Status development websh3.5 and documentation
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> We're somehow behind schedule: we planned a release by end of last
> month. I would appreciate, if we could concentrate on the important
> stuf now, so the effort we put into the project actually gets us
> somewhere.
> - Are there any code issues that still need to be looked at?
Yes - we need a way to get the location of the script for mod_websh
stuff. We also need to fix the session stuff, along with a few
makefile tweaks, maybe.
> - What's the status of the web site migration?
Depends on the above, and getting the server set up. I've been going
back and forth with Brian about this, trying to get something that is
both acceptable to the admins and to the Apache Tcl group.
> - The documentation still sucks (oops, xcuse my language)
I agree, but there's a lot of it:-( I've spent a lot of hours wading
through it, and it seems like it never ends...
> Imho we need to put most of the effort into the documentation. A few
> suggestions and issues that came up when I looked at quickref.xml
> today:
> - the commands are not consistently documented (e.g. web::tempfile
> does not have a syntax)
> - The contents is very un-readable. A few suggestions (just as a
> discussion basis):
> - Split Command dispatching and session management into two chapters
> - *Only* have the commands as subchapters (except for the
> introduction chapter) I don't know if that scales, but I'd like to
> have a cleaner Contents section
> - This would actually imply that the examples have to be moved
> somehow (either create an examples section at the end and link the
> different chapters to the examples)
> - Move the general description stuff to the beginning of the
> respective section (e.g. in the Command dispatching section the
> stuff about the cmdurlcfg)
> I know that I haven't the cool solution either, but we definitly
> have to improve the documentation not just on the content side, but
> also on the formal side.
> - Documentation is not uptodate. e.g. web::cmdurlcfg still describes
> the -protocol option
> -> we HAVE to really look at every command in detail and check the
> documentation for accuracy. And I don't see a different way than
> splitting up [info commands web::*] and assign a couple of commands
> to everyone willing to spend a couple of hours.
> Opinions?
Not much to be done other than wading through it. It's time
consuming, though:-( I've been doing my best to get the structure
cleaned up.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: Status development websh3.5 and documentation
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> - Split Command dispatching and session management into two chapters
> - *Only* have the commands as subchapters (except for the
> introduction chapter) I don't know if that scales, but I'd like to
> have a cleaner Contents section
How do you mean, exactly?
A Content section with only the Section headings? Like so:
Introduction
Configuration
Command dispatching and session management
> - This would actually imply that the examples have to be moved
> somehow (either create an examples section at the end and link the
> different chapters to the examples)
Why?
> - Move the general description stuff to the beginning of the
> respective section (e.g. in the Command dispatching section the
> stuff about the cmdurlcfg)
Sounds good. We will also have a small 'recipes' section.
> - Documentation is not uptodate. e.g. web::cmdurlcfg still describes
> the -protocol option
Ok, this is a list I think we can partially compile from the bug
tracking system.
web::response -select default should set the default channel
wrong default scheme in cmdurl (?)
Change semantic of web::putx
web::cmdurl -notimestamp: make configurable in web:::config
web::context invalidation
web::filecontext: -path is mandatory
web::log shouldn't subst by default
web::request -reset shouldn't reset all paramaters
new web::putx stuff
Will look into these tommorow.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org