I talked to one of the devs. The problem is the defer only effects a
process - it can't be tied to a session and the csp server routines are
connection pools. Here is his comment:
Some of the issues are solved in 5.1 with the ability to reject a page
before a license is taken out and also by the work to tie the login page
into the licensing so you get licensed as the logged in user if you use a
CSP login page. In general I think deferred licensing is a good thing but it
would be a lot harder to track with CSP because a single process can handle
multiple CSP sessions.
Colin wrote:
"Peter Cooper" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Gertjan
...
this would be the best solution
- what does
$system.License.DeferUserIdentification(1)
this seems to be what we want - but does it work and if so how??
Peter
All this would be a lot easier if $system.License.DeferUserIdentification(1)
worked the same for csp as it does for telnet. Currently if you set
$system.License.DeferUserIdentification(1) you can log in to a telnet app
and run 1000 lines of code without taking up a licence. However when I tried
this with csp it took a license regardless.
Now if we could just run 1000 lines of code for a csp app without taking out
the license then a) dos attacks become managable, and b) we would have a
better way of controlling licence usage during a login. by being actually
able to login and attach to the previous job's licence with License.Login.
(being 1/12).
Colin
