Implement visit counter

[following5]

All OC sites have a per-cache "visit counter" (page view counter), which should be updated when a cache listing is presented to the user.

OCPL simply increments this counter on each request of viewcache.php. OCDE increments it through an Ajax request when the viewcache output is displayed in the web browser, and eliminates duplicate views by the same user or IP within 24 hours.

OKAPI currently does not update the counter. I think we need an new method for that, which should be called by the application each time a cache description is presented to the user. Then it can update the view counters in the same way the OC site does.

E.g. services/caches/viewed?cache_code=... with auth level 1.

There would be some potential for misusing this feature, especially on OCPL sites. Maybe some protection should be added; I would prefer a complete logging which allows later analyzis and correction, but may create vast data amounts.

[wrygiel]

Ok! How about just wrapping the code in if (OCDE) { do something } else { do nothing }, at least for now?Also, the "do something" part may call an external function from OCDE's code (as opposed to writing the code directly in OKAPI).

[wrygiel]

Two more notes:

1. You should probably also add a "value to increment" parameter. So that clients will be allowed to increment the counter by 20, instead of calling it 20 times (e.g. after a prolonged offline status).

2. I don't think programmers will care to implement this. I don't see any kind of "reward" for them in this.

[following5]

I will try to avoid redundancy by moving the logic into a database stored procedure instead of calling OCDE code.

It will be fine to incement it just once after an offline period. Merging subsequent geocache views by the same user into one is exactly what is intended.

I don't think programmers will care to implement this. I don't see any kind of "reward" for them in this.

except if they happen to be geocache owners and would like to see a more appropriate view count in their cache listings. ;)

[following5]

What about delivering an < img > tag in each geocache description, which refers to a PHP script on the OC site, that will do the counting and return an empty image? This would be similar to the curent OCDE implementation, would not affect the API and make it work instantly with any OKAPI client. May be implemented for OCDE first, OCPL may decide to add it or not.

[following5]

The local PHP visitcounter script URL may be configured in local OKAPI settings; OKAPI would deliver the < img > tags if the setting is present.

[following5]

Or we may exactly copy the OCDE implementation and do it via JS/AJAX. Advantage: Will not be triggered by search engines, if someone decides to put the geocache descriptions online somewhere.

[wrygiel]

Images are precached by some apps before the geocache is viewed, for offline use (I myself use this mode quite often), so this won't be accurate in this case. By default, Javascript will not be executed when geocache is viewed in an app, so this also won't be accurate.

BTW, some users could treat this as possible invasion of privacy (especially if these methods could, in theory, be used to spy on specific users).

[following5]

Images are precached by some apps before the geocache is viewed

The image URL would contain an argument with the geocache code, so the caching would occur on a per-geocache basis. Would filter out repeated views of the same geocache by the same user, which is fine.

The hypothetical search engine problem can be solved via robots.txt.

BTW, some users could treat this as possible invasion of privacy (especially if these methods could, in theory, be used to spy on specific users).

The OC source code is open, so anybody can verify that there is no user-related information recorded here. Other than the OKAPI protocol on OCPL sites, which does a complete and infinite recording of user activity!

[wrygiel]

The image URL would contain an argument with the geocache code, so the caching would occur on a per-geocache basis. Would filter out repeated views of the same geocache by the same user, which is fine.

What I meant is, people often download images from geocaches which they never actually open. I often download all caches (along with all their images) from the area, before I go for a hike. Then, I visit only one or two of them. (However, I'm not sure how many cachers do that.)

[following5]

Ok. This may be tackled by discarding consecutive requests by the same IP address within less than e.g. 15 seconds. Automatic download will usually go faster, manual views slower. The whole view counting isn't precise anyway, if should just give a reasonable estimate of how many users viewed the geocache.

[wrygiel]

Yes, that seems to be the best possible strategy. Since only OCDE requests this feature so far, I think you can simply include the reference to the existing script in OCDE cache descriptions, right?

[following5]

The existing OCDE code does the JavaScript thing, so the called script does not return an image and has no mass request protection. Will be easy to write a new script for that; the counting logic alredy resides in a library.

(But I am currently completely out of OCDE development, technically and organisational, reluctant to change that. A year ago, I could have implemeted, tested, released and fine-adjusted this within two hours. Today it would take days or weeks, due to all the bureaucracy, restriction and control which has been set up by the new OCDE development "leaders". All annoying, no fun.)

[wrygiel]

So, what exactly do you propose? We should not reimplement the same logic in two places, especially if it is needed by OCDE only.

[following5]

It is needed by OCPL as well - there is a similar visit counter in PL code, which currently does not work with OKAPI (see initial posting above). I can't imagine that PL developers really wish to stay with this problem ...? @deg-pl : Are you sure you want your geocache listing visit counter NOT to work with OKAPI clients, i.e. visits by mobile users are not counted?

[wrygiel]

So, you want to add a GIF-serving endpoint in OKAPI, which would update:

a) existing counters, directly in OCDE's (or OCPL's) databases?
b) some new counters, in OKAPI database?

Similarly, where would you keep information about recent IPs?

c) in OCDE/OCPL database?
d) in OKAPI database?

My guess is that you are aiming at A+C?