Re: How should a timed session be implemented?

in reply to How should a timed session be implemented?

As I see, it your problem is not a perl problem but a business problem.

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?

Comment on Re: How should a timed session be implemented?

Replies are listed 'Best First'.
Re: Re: How should a timed session be implemented? by soon_j (Scribe) on May 06, 2004 at 08:22 UTC
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	[reply]

Replies are listed 'Best First'.

Re: Re: How should a timed session be implemented?
by soon_j (Scribe) on May 06, 2004 at 08:22 UTC

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

[reply]

In Section Seekers of Perl Wisdom