Forum OpenACS Q&A: Re: Clickthrough Package

Collapse
3: Re: Clickthrough Package (response to 1)
Posted by Ola Hansson on
The clickthrough package is not in a functional state at the moment, and I'm afraid I might be responsible for it not working due to my ignorance in the early days.

I want to fix this so that the package at least works in 5.0.

Clickthrough is designed to be mounted multiple times (or just once of course), under various nodes where you'd like to survey the traffic. The package is keeping a single cache for all its instances and there is a sweeper proc scheduled at package initialization time. This is set to run at regular intervals and is responsible for updating the database when the cache has reached a certain number of clicks. Now, the problem is that we have _package instance_ parameters that control the interval at which to sweep, and the number of clicks at which to dump to the database, when it ought to be a package level parameter. Also, there are calls to "apm_package_id_from_key clickthrough" which will probably fail if there are more than one instance of Clickthrough mounted in the sitemap.

My suggestion is that - for now - I either hard code the values (interval 300, click_count 100, say) or I move the package instance params (CacheSweeperInterval and MaxNumberOfCachedClicks) to acs-kernel. Hmm, since Clickthrough is not a core package, it might be a bad idea to put the params in acs-kernel ...

What do others think about that?

(Sooner or later, we _really_ need to have package parameters in addition to package instance parameters.)

/Ola

Collapse
4: Re: Clickthrough Package (response to 3)
Posted by bill kellerman on
i'd like to use the package, and if you are already looking at fixing it up, i'd really be in support of that. as far as what to do to get it up, do whatever is easiest to get it running most stable and stick on a big red flag, "real version due in v5"...?

first question, what is the logic for having multiple instances of clickthrough at all?  why not just the umbrella package over all subsites?  a set of referrer-to-target maps are the same thing no matter where they come from -- it's the  task of administrative reporting to make a presentational data distinction.  ...something.  it's too late for me, i'm missing some functional logic.

second question, assuming multiple instances exist for a reason, then assigning a cache per instance along with instance level parameters.

or similar to what seems to be done in other place in the openacs -- package level sets parameters and it's own cache.  an instance generates it's own cache, inherits parameters from package level to be configured by the user.

i hope this doesn't come off as condescending.  i'm still way trying to catch up on everything, so i'm really just trying to figure things out.