[libdb-develop] Installation: CGI-BIN, ExecCGI, and Media Files

[Morbus I. <mo...@di...>]

Hey all. I wanted to chat with you regarding the installer and
a conversation I got into with an early tester of said code. In
a nutshell, it comes down to "how casual is casual?".

The conversation occurred over what we can expect the user to
handle, and what we can expect the installer to handle for the
user. Before I get into the technical side of things, brush
up on the User Profiles shown here:

  http://disobey.com/noos/LibDB/?ProjectGoals

We'll be talking about the "casual user". I'd like to state
that my definition of the "casual user" contains these maxims:

 * the user does not have shell access to their web host.
 * the user is not the root user at their web host.
 * the user has FTP'd the LibDB files to the web host.

With that in mind, the technical aspects. There are two different
ways (actually, three, but mod_perl is not important to this
discussion) a user can run LibDB:

 * in a /cgi-bin/ directory provided by their web host. all
   files in a cgi-bin are treated as executable. this means
   that media files, like GIFs, JPEGs, CSS, etc. CAN NOT be
   viewed from under this directory. /cgi-bin/style.css would
   cause an Internal Server Error as Apache would try to
   execute it.

 * in an ExecCGI'd directory. ExecCGI is a way to say "ok,
   anything in this directory that has a .cgi extension
   should be considered an executable script; everything
   else should be considered a normal file to be handled
   as you would any other day of the week".

LibDB, and the installer, require media files for proper visual
operation. These will include javascript files, CSS files, and
image files. These files are stored in a directory called
media_files/. Nothing too exciting here.

One of the very first steps the installer takes is to make an
attempt to access these media files. This will ensure that the
user can properly see images and styles that are part of the
installer program (as well as the rest of LibDB).

Currently, the installer loads an external CSS file (located
in media_files/). If a certain bit of text in the installer is
red, then the CSS has been loaded successfully. This typically
means that the user is under an ExecCGI directory: media_files/
style.css does not end in .cgi, thus Apache serves it as normal.

If the text is NOT RED, however, it means that Apache was not
able to serve the style.css. Currently, this means "the user
has placed the LibDB files into a /cgi-bin/ directory". The
installer instructs the user to moves the media_files/ directory
to a web accessible location, and enter the URL to the newly
moved directory. The user enters the URL, the script reloads,
and if the text is red, everything is fine, and the installer
continues.

Here's the question: "shouldn't the installer
move the media_files/ directory for the user"?

I certainly like the idea. Currently, if
the text is NOT RED, the assumption is that:

 a) the user will open up their FTP program.

 b) the user will navigate to their LibDB directory.

 c) the user will move the media_files directory to
    a web accessible location, without fail.

 d) the user will enter the URL to the location
    they moved the media_files to, without fail.

Assuming no failure, that's another four steps the user must go
through before they can actually install LibDB. Is this a problem?

The conversation I had basically went (and to the person
in question, I'm paraphrasing rather badly to make this
email more concise <g>).

 THEM: Well, the installer should detect that the loading
       of the style.css failed (with a check of HTTP
       code 500) and move the media_files for the user.

   ME: Yeah, but I'd still have to ask the user for a directory
       to move them into, which could potentially be dangerous,
       because it assumes the user knows the full path of
       their web directory. That's not something normal
       people know - at the very least, it'd be a call to
       their webhost, or a rummage through paperwork.

 THEM: The installer shouldn't ask them for the directory,
       it should just move them automatically. You can
       program heuristics for this.

   ME: I certainly agree - some /cgi-bin/'s are subdirectories
       of the user's root (so I could move "up", check for the
       existence of .html files, and copy) or are in the same
       directory as an "htdocs", "htweb", etc. (so, move "up",
       if failure, look for "htdocs", copy), but I still worry
       about this. By not prompting the user, we're assuming
       that are heuristics will NOT fail. And what happens if
       the user already has a directory called "media_files"?
       What happens if the user, a month from now, updates their
       site, sees "media_files", has no idea what it is ("I didn't
       place that there!") and deletes it?

 THEM: Yeah, but the user could just as easily say
       "pfff, this is hard", and never use LibDB again.

So. I want people's thoughts. The core question is: should
the installer move/copy media_files for the user, or should
we assume that the user will be willing to do it?

At this point, my feelings are:

 * the user has already uploaded the LibDB directory via FTP.

 * the user probably already has a website (I don't know of
   many non-website-users that would explore web-based
   software as opposed to a native implementation).

 * the user knows where .html files go, and thus, moving
   the media_files directory to the same place won't be
   an extra step that causes much duress.

 * copying automatically is awesome, but has too many
   things to worry about (heuristics, future deletion, etc.).

-- 
Morbus Iff ( cheese and rice saves )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
-- 
Morbus Iff ( is this a cut out bath-poster Morbus, or what? )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus