Dion Rasmussen wrote:
> I was simply suggesting a different approach. You know to allow "masking"
> which locations of your site to have visit incremented counters from
> within httpd.conf or sub-configuration.
No, I did not know!
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?!
But, what would be the http.conf configuration to keep the visit counter on a
URL?
like this:
-snip-
<Location ~REGEX>
PerlFixupHandler Counter::Module
</Location>
-snip-
and done from the locations matching REGEX or using normal Directory directives or even specified in .htaccess files...
> > About "advisory-locking", I do not understand what you mean to say. Could
> > you explain?
>
> I meant using files and directories instead of some special database.
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...
> >Just a comment, using .htaccess files is said be bad for performance:
>
> What else are you suggesting that is more secure and fast than .htaccess?
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.