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?

[following5]

If we do an implementation for both OCDE and OCPL, I would prefer A+D + a facade interface, so that at least OCPL may decide to replace it's very simple and unprotected visit-counter implementation with the OKAPI implementation.

[wrygiel]

If OCPL and OCDE developers agree with this, then okay.

[following5]

@teiling88 Do you agree with this proposal?

@deg-pl Could you check with the OCPL team if you would like to have an OKAPI visit counter implementation as proposed above?

[deg-pl]

@opencaching/opencaching-pl-lead-programmers read this thread and write your opinion please.

[harrieklomp]

I cannot say if this should be implemented yes or no. If i am correct this counter has been changed/improved a while ago (Feb - March) and there has been made a new table "cache_visits2" for it in DB. All visit counters where reset to 0 (zero). If OCPL code does implement this, please do not reset these counters again.

Just my thoughts :-)

[kojoty]

Hi,. I'm not sure if I understand how the idea of okapi counter finally works.

I agree that OCPL implementation doesn't count okapi accesses but we changed a way how the counter is working a few months ago and from my point of view the most important is not to reset its value again.

Please note, that now OCPL counter is user-aware and next inc. is after the week from the last visit.

If you find the way which allows to extend counter to okapi it's Ok for me.

Regards, kojoty

On Sunday, August 20, 2017, harrieklomp notifications@github.com wrote:

I cannot say if this should be implemented yes or no. If i am correct this counter has been changed/improved a while ago (Feb - March) and there has been made a new table "cache_visits2" for it in DB. All visit counters where reset to 0 (zero). If OCPL code does implement this, please do not reset these counters again.

Just my thoughts :-)

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/opencaching/okapi/issues/450#issuecomment-323570331, or mute the thread https://github.com/notifications/unsubscribe-auth/AC0wKENioh9s5G3Uf9hsGDJQa7Xq4yYnks5sZ-hngaJpZM4Lagmm .

[following5]

Of course counters should not be reset.

Please note, that now OCPL counter is user-aware and next inc. is after the week from the last visit.

That's similar to the OCDE counter, which is also user-aware but has a timeout of one day instead of one week. I will have a look at both implementations in detail and try to resemble them closely.

What seems to be missing in OCPL code is a protection against robots - looks like search engine accesses will be counted; so your visit counters since the reset may have primarily counted Google-robot requests. OCDE blocks this through the JavaScript/AJAX trick, which is not available for OKAPI.

Altogether then, I think we should go for A+C+D: Use the existing visit counter tables for the per-cache User- and IP-related filter, and add an OKAPI table for global IP-based filtering of mass requests.

[following5]

Use the existing visit counter tables for the per-cache User- and IP-related filter

... so that local code and OKAPI share the user/IP information and cooperate in per-cache view filtering.

[following5]

That's similar to the OCDE counter, which is also user-aware but has a timeout of one day instead of one week. I will have a look at both implementations in detail and try to resemble them closely.

Uhhh... OKAPI does not know about users here. It can only evaluate IP addresses, which are more volatile; so the one-week filter for OCPL would not work properly. :-(

[following5]

The can be circumstances when the counter dummy image will appear as broken image in the browser. E.g. when the listing was downloaded via GPX, and there is no internet connection when displaying it. I am not sure if this is relevant.