The Problem:

It's difficult to come up with an interface that allows the user to painlessly enter all the initial hash code and template information.

Accepted Solution

1. The user generates the MD5SUM or SHA1SUM file for all downloadables.
2. The user logs into Bouncer and uploads that file.
3. Bouncer then presents that file to the user with check boxes on each line (perhaps some automatically checked based on some rule system)
4. The user checks off all files that Bouncer is to know about
5. The user presses an OK or COMMIT button
6. Bouncer hands off the checked data to a Python script
7. The Python script goes through the list entering each file and hash codes in the database. It will even deduce and construct an appropriate template.
8. Any unresolvable ambiguities will be reported back to the user.

Discussion

Lars already has a proof-of-concept Python program that will take the hash file and make the appropriate entries in the database including the deduction of the template.

The relative path names in the hash code file are not complete. They are missing the product/version parts of the path. We'll have to ask the user to fill in the missing information bewteen the end of the mirror base path and the start of the relative path in the file. They have two options for specifying the path.

1. put it in as a literal (ie. "/firefox/1.0.2/") whereas the Python load script will templatize it
2. put it in as a template (ie. "/${pv_product_name}/${pv_version_name}/")

The PHP page that lets the user select the lines from the hash file should have a form with the following variables names:

• pathprefix - the intervening path fragment between the basepath and the hash file specified path
• checkboxes - a boolean, one for each line
• pathname - the URL/path fragment that bridges from the mirror base URL to the path in the hash file
• hash - the hash code from the hash file
• conflicts - a boolean - T: overwrite; F - Ignore

Questions

• How does a PHP script invoke a Python script?
  • make the python script a cgi-bin script. When the user presses the OK or COMMIT button, that invokes the python cgi scriptby submitting the form. The Python script does its thing altering the database and then posting its results back.
• How does a Python script report results back to a PHP script?
  • On completion, the Python script returns an HTTP redirect to a PHP script that can display the results.
• How are ambiguities reported back to the user? An then how does the user address the problems?
  • just list the problems

    01 - AMBIGUITY - two files conflict:
         './linux-i686/ast-ES/firefox-1.0.installer.tar.gz' is OS 2, Product 1, Locale 1
         './linux-i686/ast-ES/firefox-1.0.tar.gz' is OS 2, Product 1, Locale 1
    02 - UNMATCHED - the file does not match a known product, os, or language
         './linux-i686/xpi/pl-PL.xpi'

  • let the user fix the problems manually through the rest of the interface
  • problems should be minimal because the user can select which lines of the hash file are to be used.
  • the user always has the option of resubmitting the has file, or even editing it.
• Do other projects use a hash file system like Mozilla does?

I'm not sure we want to go there discussions

If the input hash file contains relative paths, do we need a template system at all? The database schema could be reduced and merged. The 'downloadables' table is a join table between 'files' and 'mirrors'. The 'Files' table is a join table between 'downloadables' and just about everything else. The 'Files' and 'Downloadables' table could be merged, eliminating the need of the 'templates' table entirely. SQL statements across the whole system could be simplified.

Proposal 2 (also known as Wild Idea #1)

Assume the same Python program as in Proposal 1. This time we added another column to the OS table. Values in that column would represent the file extension used for each operation system. The template deduction scheme would then be able to differentiate between entries in the hash file representing valid products and entries representing other files. There would be no need to have much of a user interface at all. We'd need to fetch the bridge URL fragment.

Discussion

This is brittle. It can work iff all products use the same file extension within an OS. It also doesn't entirely eliminate the protential for conflicts.

Perhaps it would be better to use the registered file extension idea to help the user interface. Rather than adding it to the OS table, add the information as condiguration to the user interface. When the user interface (as define by Proposal #1) displays the uploaded hash file with check boxes, it prechecks the items that have registered extensions.