Re: CGP/1.0 specification
luotonen@ptsun00.cern.ch (Ari Luotonen)
From: luotonen@ptsun00.cern.ch (Ari Luotonen)
Date: Fri, 19 Nov 93 11:58:55 +0100
Message-id: <9311191058.AA02218@ptsun03.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: CGP/1.0 specification
Rob:
> As Tony and I were discussing, perhaps we should not make the unescaped
> query string available as an env. variable at all but simply put it on the
> command line.
Good.
> * script /extra/path 'foo=' 'bar' 'bar=' 'foo'
> *
> * In this case equal signs in values (or even names) wouldn't cause
> * any confusion, and spaces in values aren't a problem, either.
>
> But the equal signs are frivolous, and the script just has to parse them out
> anyway. So why put them in there?
In the common case for a given script there is a certain well-known
set of field names that it can expect. In that case it doesn't need
to parse ='s away, but strcmp with fieldname possibilities that are
appended with an equal sign. This makes scripts a little clearer to
read and debugging easier as the tester can see which one is the field
name and which is the value. But ok, if everybody thinks this is oh so
stupid I will seriously consider taking my word back a bit and strip
those ='s away, if that's what it takes.
> [Should Location: be absolute or virtual]
>
> As far as implementation, I can easily do either. The question is, then,
> what will the scripts want? Would it be difficult with the CERN server to
> enter the document mapping process with an already translated pathname? If
> it's overly difficult,
Try impossible :-( at least if I want to do it properly. Rule file
can do many-to-one mappings. Reverse to this would sometimes
produce funny results.
Well never mind that, I might be able to do something about it,
but as George Phillips said:
> As to the question of whether Location: should interpret a virtual
> of real pathname, I'd say that it should be virtual. If the
> script wants to output a real path name, it can "cat /a/real/path/name".
> Also, the virtual path name gives it the flexibility to activate
> some other gateway.
I couldn't agree more; especially the last point is very important.
-- Cheers, Ari --