You might also consider trusting your customers. Being treated with respect often helps a customer feel better about the product they are buying.

As BUU as mentioned HTTP does not lend itself to this type of business procedure, and as so, a re-think of the goal of your project is on the cards.

The only way of doing this is, each page view issues a token, and takes the delta from the previous view. If the delta is > n then you start/stop/reset your timing calculation.

This is ultimately flawed as it relies on the user keeping their cookie, if a user throws it away, then the process will fall apart.

Probably the best way to make cash off the web is subscription.

Think about this: Of your extensive travels of the internet (web), which is a well mature product, how many sites have you come across that use a time based algorithm to make money, and how many subscriptions sites have you seen?

You are absolutely right, this is an implementation problem as well as a business framework problem rather than a Perl one. However, in the country I am into right now (which is only fund of "chatting over IRC's" rather than on real e-commerce), implementing online subscriptions might not be very attractive.

The initial framework involved purchasing an access code (sold physically on local stores) and using these codes to gain access to the site for a period of 1 month. After the one month has elapsed, he could either buy another access code should he decide to continue. This works the same as a paid subscription in some ways.

However, owing to the "cleverness" or "stupidity" of some users, they allowed their accounts to be shared. This fact could never be controlled. I can't just simply track their IP addresses... it won't work.

This scheme was changed to involve a timed access. On every click of the page, the delta is taken and the allowed no. of hours is decremented. This is implemented through a server-side session management, so everytime a user asks for a piece of information, a delta is derived and the session variables are decremented accordingly.

This process definitely would work. The main flaw is when the user last asks for an information, he could either terminate a session illegally by not logging-off. He could stay on the same page with the same limited piece of information for several hours... but who cares? He may just have left his session intentionally or not. Because of this illegal termination of session, I'll assess him with a penalty (like 5min to 10mins).

Thanks

I've got no technical advice for you, but just about every phone company or whatever, if they charge for things on a time basis, have some notation of what the "to-the-nearest" unit is.

For example, one phone company here in Australia advertised that its phone plan calculated calls to the nearest second, not to the nearest minute, as with a competitor.

So if you're going to do what you outline above, I think you owe it to your customers to spell out that the service is "calculated in increments of ten minutes" or "to the nearest ten minutes" or whatever.

For instance if I log on six times today, for one minute each, you're going to charge me for an hour. I might be unhappy about that...

I don't think "to the nearest 10 minutes" is what he's getting at all. I assume, from what he says, if you properly "log out" then it'll track exactly how much time you've spent. What he's talking about is guessing when people have actually left, but haven't logged out. His idea was a 10 minute penalty.

Well it's ambiguous if you put it like that. He never said "there's a logout procedure people are expected to follow" and even if there is, then it's *that* that he needs to spell out to users.

---




($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print

I agree with you. The statelessness of the HTTP protocol gives rise to such issues like the ones I'm bringing out right now.

The pages that the users are viewing are practice exams from subjects being offered by a training center. The length they stare on a page is dependent on how fast they can solve the problem. Logging-out is mandatory. However in some unforeseen circumstances like a power failure, I wouldn't want to charge-up those "minutes".

I had once an "unlimited access" scheme, but the problem this brings is that user simply shares his account with another. To addresss this, we agreed to have limited access time for users.

I believe giving the user a 5 min to 10 min penalty for not logging-off properly is still fair. I wouldn't bother if they stay on the same page for two hours since all they can do is to stare on a single page with a single question... and nothing more. To get additional information, they need to navigate to another page.

Then why not rate based on pages viewed? That way you at least have an accurate measurement.

You could load a hidden 0 width frame with a metarefresh to your script. So every 10 seconds that frame reloads telling your server to take 10 seconds off this users account. When the user closes the window then it stop taking time off and if their time runs out you can have the frame reload the whole page telling the user they are out of time. It could even be a slightly visible frame with a counter. Since its all in frames the user realy wont notice or care, just make sure that your page wont load outside the frame or users could just grab the URL to it and skip the timer part.


___________
Eric Hodges

This works for me.

I use a mix of hidden frames, DOM, JS and lots of perl for a "threaded" website.
The thread frame refreshes itself every x seconds and updates a db field.
And a cron job checks every 5 minutes, whether a user is actually online.

So I can force logout :-)


cheers

Could you elaborate on your cron job... I am interested in this implementation. Thanks.