Re: New feature: visit counters

[Dion Rasmussen]

OK, let me explain.

Each offer can be stored (dynamically) as a file and shown off (dynamically eventually cached statically) with a HTML template using the standard file-system as the database-engine instead of some special database.

Furthermore the standard HTTP authentication can be used with eventual secure socket layer constraints instead of relying on cookies for security.

Sometimes special databases can be useful but it's a bit easier and a better finish to just use the standard file-system for varying data as well as static data, for the sake of data-management-ease as well as security layout.

And once again, a database transaction specification is as complex as locking a file :)

Regards

On Tue, May 6, 2008 at 10:48 PM, Davi Leal <address@hidden> wrote:

Dion Rasmussen wrote:
> > I suppose it would be better to use the data base which we are already
> > using to keep all the information. So we can expand it easily.
>
> Aren't you/we already storing each job offer as a file in some unix-like
> security context, if that's the case we might better "stick" with each
> filename?!

No, we are not storing each offer as a file. The steps are as follows:

 1. Get the offer information from the data base.
 2. Apply a HTML template to it.
 3. Translate it to some of the webapp supported languages:
    Portuguese, Spanish, Italian, Russian, ...
 4. Show the final information to the webapp user.

The project is not using static HTML files but dynamic output from the PHP
scripts.

 

> > But, what would be the http.conf configuration to keep the visit counter
> > on a URL?
>
> like this:
>

>       <Location ~REGEX>
>          PerlFixupHandler Counter::Module
>       </Location>
>

> and done from the locations matching REGEX or using normal Directory
> directives or even specified in .htaccess files...

IMHO, as we are not using static HTML files we can not apply such
visit-counter design.

> > Database is said to be a better solution for a multi-user scenario. The
> > read/write locking is solved by the database layer, so you do not have to
> > worry about it. Developing the locking support by hand would be a lot of
> > lots of work!
>
> Not anymore work than specifying a database transaction which is the
> same...

Good database engines are complex. IMHO we should not develop our own data
base engine to develop our own read/write locking and multi-user support
algorithms.

There are already several free software database engines out there which we
can use.  Using PostgreSQL is a good option.

> > Non using .htaccess is more fast than using it.
> > It is not needed to use .htaccess
>
> Anyways for the sake of access specifications, .htaccess is usually more
> convenient than using some script.

We are using the PHPSESSID cookie to check permission per user. We do not
check permission per file, we check it per user.