Re: template path problems

[Tim Janik <timj gtk org>]

On Fri, 9 May 2003, Alper Ersoy wrote:

> Tim Janik:

> > as an aside, it's inherently unsafe as people could point their
> > browsers at http://beast.gtk.org/cgi-bin/logo-submissions/perpage/34
> > or so similar things.
>
> That's not an issue:
>
>   - One line of code, ie. $perpage = 30 if $perpage > 30;
>   - Since those are thumbnails, 34 of them won't get any bigger than
>     a beast tarball.  Also, logical browsers and proxies will not try
>     to open 34 connections at a time.

no, $perpage is just one example, $IMAGE_ROOT would be another,
and you certainly don't want people to be able to specify that,
do you?

> > can we please go for a simple and explicit solution like:
> > --- cgi-bin/screenshots.cgi ---
> > IMAGE_ROOT=images/screenshots/
> > HTML_TEMPLATE=screenshots.html
> > exec gallery.cgi
> > --- cgi-bin/screenshots.cgi ---
>
> I can easily see a pattern in the above snippet.  Why not shorten it
> to a single
>
>   $0

because i might change the image path at one point,
or have a different template file browse those images (files in
case of the contrib section) as well?

> and let the script evolve that to
>
>   IMAGE_ROOT=images/$0/
>   HTML_TEMPLATE=$0.html
>
> and since the script is gallery.cgi, no need to explicitly exec
> gallery.cgi ($0 is different than the script's real name, it's what
> apache calls it, ie. via a symlink a la gzip vs. gunzip).

alper, i just don't see an advantage in tying script name, html template
and image path together in a fixed manner. it makes me wonder not if, but
how soon that setup will break for future needs.
on gunzip, it's a convenience feature by gzip, i can still unzip my files
with -d, just like i don't need to rely on convenience aliases for grep's
-F, -E or -R.

> > i don't see what "Ultimate configurability" is missing if
> > you specify things explicitely. i'm just getting confused
> > and don't know what magic naming/links etc. the scripts
> > rely on (and if you explain i'll prolly have it forgotten
> > in a month).
>
> Of course you will forget.  I will forget too.  But then, we will
> forget how we added current galleries also.  So we will look at the
> cgi-bin directory, and notice this:
>
>   $ ls -l cgi-bin
>   -rwxrwxr-x  6 timj beast      10001 May  9 gallery
>   -rwxrwxr-x  1 timj beast          7 May  9 logo-submissions -> gallery
>   -rwxrwxr-x  1 timj beast          7 May  9 screenshots -> gallery
>
> versus
>
>   $ ls -l cgi-bin
>   -rwxrwxr-x  6 timj beast      10001 May  9 gallery
>   -rwxrwxr-x  1 timj beast        543 May  9 logo-submissions
>   -rwxrwxr-x  1 timj beast        606 May  9 screenshots
>
> Tell me which one is more obvious ;)

you probably won't believe me, but for the former version my
initial impression was "what magic is going on there? damn,
i'll have to read through the whole script to figure what
the effect of using 'logo-submissions' vs. 'gallery' is."

for the second i thought, "ah, alper probably went through the effort
of creating small PATH= config files that tell me exactly where things
are, nice of him. but gallery shouldn't be there, it shouldn't be
accessable by the user.".

> If the CGI script will be a part of texitheque, I will document it.
> I will also add a part about it in /web/beast/NOTES.

that would be good. there might come others though, so maybe texitheque
should have an extra texitheque-cgi/ dir for such scripts (or
texitheque-contrib/ if that's not just for cgi scripts but maybe perl
utils or similar), and the beast site as well (it'll be your job to keep
that in sync then, by simply copying stuff over).

the scripts (logo-submissions, screenshots) would then
  exec ../texitheque-cgi/gallery.whatever-extension-alper-likes

>
> --
> Alper Ersoy
>

---
ciaoTJ