Aaahhh so it's not impossible to do, just 'a lot harder' ;-) I'll look forward to this being implemented by one of the clever devs. Colin
"Bill McCormick" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 > > > > > > > >
