Re: deploying multiple picolisp web applications

2009-01-19 Thread Alexander Burger
Hi Tomas, > Then a better and generic solution might be that we parse the "Referer:" > ... > This would be also useful for other purposes, and could be used in the So I added it to "lib/http.l", available now in the testing release. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de

Re: deploying multiple picolisp web applications

2009-01-19 Thread Alexander Burger
Hi Tomas, > I think httpGate is > more complicated than httpGate0 and also it is broken in the sense > that it does not allow to display a *proper* error or timeout page. I disagree. 'httpGate' should not try to be clever. It should not connect to the first port by assuming that somebody will han

Re: deploying multiple picolisp web applications

2009-01-19 Thread Tomas Hlavaty
Hi Alex, > But still I want to keep simple things simple. 'httpGate0' connects > back to the first port without asking, which I think is the worst > default behavior. I guess that it depends on the point of view. I think httpGate is more complicated than httpGate0 and also it is broken in the se

Re: deploying multiple picolisp web applications

2009-01-19 Thread Alexander Burger
Hi Tomas, > > ... (though both behaviors are possible with the > > "void" as well as with your soution), or why it is not powerful > > enough. > ... > example of the default server I sent implements exactly the kind of > page with timeout you described earlier. I know. That's what I wrote (should

Re: deploying multiple picolisp web applications

2009-01-19 Thread Tomas Hlavaty
Hi Alex, > So with a page pointed to by "void" you can do anything you like, No, you cannot compute the url where to click/redirect. The url is hardcoded in the 'void' page. > I still don't understand why you think it is more user-friendly when > the user is thrown back to the app's start page

Re: deploying multiple picolisp web applications

2009-01-19 Thread Alexander Burger
Hi Tomas, thanks for the proposed solution! I believe it is useful, but I would not want to put it into the PicoLisp release. I still believe the current solution is sufficient, and much simpler. It does not need additional concepts like a predefined application name, a session id schema, and a

Re: sort

2009-01-19 Thread Tomas Hlavaty
Hi Alex, > now I changed 'sort' as discussed, accepting an optional function thanks a lot! Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: sort

2009-01-19 Thread Alexander Burger
Hi Tomas, now I changed 'sort' as discussed, accepting an optional function argument. It is available in the testing release. As described, some data have to be preserved in stack frames, to be gc-safe. The code is quite a mess with that now, but the changes were straightforward. The performance

Re: deploying multiple picolisp web applications

2009-01-19 Thread Tomas Hlavaty
Hi Alex, > 1) lib/http.l should have *AppName variable. *AppName could be either > 2) *SesId should be > 3) lib/http.l should be changed to allow for "better" handling of The changed lib/http.l is attached. It should work the same for any existing deployments as the new behaviour is superset to

Re: deploying multiple picolisp web applications

2009-01-19 Thread Tomas Hlavaty
Hi Alex, >> > A direct link to the "default" port might not always be desired, as >> > this is often not the main application (but some other "home" page). >> >> I cannot see how this can be a problem? Having the same > > As you know, we are using PicoLisp and 'httpGate' for web applications. >

Re: deploying multiple picolisp web applications

2009-01-19 Thread Alexander Burger
Hi Tomas, > > A direct link to the "default" port might not always be desired, as > > this is often not the main application (but some other "home" page). > > I cannot see how this can be a problem? Having the same As you know, we are using PicoLisp and 'httpGate' for web applications. On the d

Re: deploying multiple picolisp web applications

2009-01-19 Thread Tomas Hlavaty
Hi Alex, > A direct link to the "default" port might not always be desired, as > this is often not the main application (but some other "home" page). I cannot see how this can be a problem? Having the same configuration, the only difference is that with httpGate you would get "connection error"