Forum OpenACS Development: Tracking downloads of files or how to attach methods to objects

>Its more a thing where we want to attach capabilities to an object per

package instance or site wide. ie: this could be used to say "these objects are searhable,commentable, record views for these objects"... or am I off track.

>
>Dave

the question is, do we need the ability per object, per object type, per package/object_type combination or site wide. But attaching capabilities sounds to me like something that could be achieved through standard methods which could then be extended, by whatever means we choose.

As an example I was wondering why we have /file and /image and /o, where /o should be able to handle file and image as well.

But either way, the question remains how to "fix" the immediate need of having views tracking even in the /file /image and /o pages provided by acs-subsite. Maybe you guys have some ideas on that? The easiest approach (for me at least) would be to have a callback hook with the object type, somehthing like "object::view -object_id -object_type" (and yes, we are again having the fundamental discussion here, should we call only the implementation of the object_type or should we have it call all existing implementations which could then discard the callback if the object type is not dealt with in the implementation. 1) is better performing, 2) gives greater flexibility to register custom implementations).

This seems like a difficult question in the context of a database. Although OpenACS defines objects as a row of data from one or more tables, new objects are created anytime you write a select that spans objects or is a subset of an object. So a file object may glue itself onto another object, together forming something new, at any time. This is no different in reusing an image on a web page. The page combines many objects into one. In order to really control this and be able to track usage, you would first need to control the process of building up objects so that you could always trace every 'potential' use. Once you can do this, you can then monitor the larger objects and do an accounting of the objects you are interested in.

I think it would still be largely pointless and impossible to monitor every usage, as you would still have to define what it means to access an object: is just grabbing the id count? Using the metadata in a where clause? Creating a page which references the object?

Although it seems like an interesting exercise to have a god-like monitor, this type of functionality is purely administrative. The point of a user interface is not to provide back doors into the object storage, but to combine objects into something more generally useful, and expose objects in combination. A few months back I commented on the installation on OpenACS.org of a package which sniffed around in administrative data and exposed connections which were otherwise hidden. The problem is that you have one large storage room and everyone has the same key: controlling what is exposed, how and to who is a difficult problem.

Assuming that you don't care about blocking access, couldn't you register a trace filter (1 or more) and decode the url/user/etc.?

Can I use xotcl request monitor without xotcl?