1. I chose the colours to aid in reading, but I tried to regroup items logically. For example I chose a weird orange for environment variables. Anyway, I'm thinking that I could use colors to represent the dependencies (what data comes from the client, what data comes from the server, and after this dichotomie, a set of colors for Apache-level APIs, CGI env-vars, and mod_python). That's a work in progress...
2. I don't know - I did not made this to distribute, just to fuel our discussion about the various way to get information about the request, and the mess it can cause. But if you guys find it worth publishing, why not.
Regarding 2c, I solved the problem by dropping OpenOffice and doing it in HTML (I exported from OO to HTML and cleaned up the mess manually). I've checked in the result in the Doc directory.
Regards,
Nicolas
2005/12/3, Jim Gallacher <[EMAIL PROTECTED]>:
Nicolas Lehuen wrote:
> Hi,
>
> Following last week's discussion about the various parts composing an
> URL and how to get them from Apache and/or mod_python, here is my first
> try at a chart that sums up what we know. It show a sample URL and how
> different components of the application server see it or contribute to it.
Interesting view. Couple of questions:
1. Any significance to the colours or are they just to aid in reading?
2. How do you envisage this being distributed?
a. On the mod_python website?
b. Once it's complete, rewrite it in LateX so it's integrated with
the generated html-docs?
c. Bundle with html-docs but generate the file (html or pdf) from
the ods source?
From the perspective of creating the releases 2.b is likely best, but
making this kind of table in LaTeX goes *way* beyond my skills.
If you see us using 2.c then we need to think about how to automate
openoffice to create the file during the packaging.
Jim
