From: Stuart D. <st...@al...> - 2002-12-26 19:49:41
|
Ian, Looks good, here are some comments. There are a couple of significantly different ways to setup and run Webware. 1) Use of global access to Webware with mod_webkit and httpd.conf referring a path such as /WK to Webware. 2) Use of global access to Webware/PSP with mod_webkit and httpd.conf redirecting .psp pages to Webware. However this does not currently work with PSP documents under ~user locations. 3) Localized access where the .htaccess file redirects references through the webkit-handler. Requires mod_webkit be installed globally in httpd.conf but allows .htaccess references to unique Webware AppServer by specifying the port to use. Note that this may currently have problems with ~user expansion too. 4) Localized access to PSP through psp-handler references in .htaccess file. Requires mod_webkit be installed globally but allows .htaccess to reference a unique AppServer instance by specifying the port to use. Note that this is broken currently when using ~user expansion, but a fix is in the works. 5) Access through WebKit.cgi. I am not clear of the issues here but believe there may be some problems with ~user expansion here as well. 6) Access through OneShot.cgi The options 1 and 2 above seem to be common. However I believe that the other options also have value, especially if an ISP wants to offer Webware, and allow users to reference their own instance of Webware. The problems I pointed out with the ~user expansion tell me that currently, not many people are trying to use it in that type of an environment. But I think the potential for large scale use there is high. I think it would be useful for the descriptions of setting up the environment to outline the various ways in which Webware can be invoked, and provide a brief description. Also, given the discussions around referencing python vs python2, and the requirement for python2, I think this should be clearly addressed. Unfortunately some distro's (RedHat) have "python" invoking python 1.5.2 still. That will cause problems for someone unless we automagically fix it to reference python2. -Stuart- > -----Original Message----- > From: Ian Bicking [mailto:ia...@co...] > Sent: Tuesday, December 24, 2002 8:52 PM > To: Webware Discuss > Subject: [Webware-discuss] New documentation: Application Development > > > I added some documentation today that gives some advice on > application > development with Webware, mostly MakeAppWorkDir with a little > on CVS. > I'd be interested on feedback -- I'd like this to become the > basis for > some conventions on distributing and handling Webware > applications. If > there's other topics that seem appropriate, or whatever. > Documentation > and enhancements can also go hand-in-hand -- some things might not be > described because there's no one good way to do them in Webware; we > might be able to fix those and document them at the same time. > > The document is in CVS at > WebKit/Docs/ApplicationDevelopment.html (the > .txt is the canonical source), or online at: > http://tinyurl.com/3tfl > > Ian > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Geoffrey T. <gta...@na...> - 2003-01-13 15:57:20
|
Randall Randall [mailto:ra...@ra...] wrote: > > I have never understood where session.value('loginid') is being set, > > why it is being deleted if it exists, why the incoming id must match > > the old value, and what is the benefit of doing request.delField(...). > > loginid is set in login.py, another Example page. The answers to the > others aren't clear to me, except that perhaps it is supposed to be a > defense against replay attacks. That's the idea. In other words, if you use the browser's "back" button after logging out to go back to the login page, then you hit the "forward" button to re-post the login, it won't work the second time. That's why we put in the one-time loginid and make sure to get rid of it right away. - Geoff |
From: Ian B. <ia...@co...> - 2002-12-26 22:19:49
|
That's a good list -- it would probably belong more to the installation documentation, which is separate (though it needs work too). The choices are mostly pragmatic. But it's a vague line -- obviously, setting up various AppServers and such is an installation issue as well, and ApplicationDevelopment.txt could flow in either direction (towards setting Webware up, or towards developing Webware/Python web applications). I'm making another document (WebKit/Docs/Tutorial.txt) which covers the web application portion -- though for an inexperienced user. Actually, I guess it's that there's two kinds of documents -- one which describes how you can do something (reference), and one which suggests how you should do something (a guide). ApplicationDevelopment is intended to be a guide, and as such could probably cover most of installation, but in a non-complete manner. In my opinion, only mod_webkit and wkcgi are worth introducing (though I haven't used standalone PSP pages, so I don't know about how that should best work). Some mod_rewrite documentation should also be included (I believe Quixote has some). Then we'd ignore thinks like WebKit.cgi, OneShot.cgi, ModPythonAdapter.py, etc. Those are options, but for 95%+ of people mod_webkit or wkcgi are the right solution, and so I think they should be emphasized. Complete (and structured) reference documentation is also very important, but that's another issue... On Thursday, December 26, 2002, at 01:49 PM, Stuart Donaldson wrote: > Ian, Looks good, here are some comments. > > There are a couple of significantly different ways to setup and run > Webware. > > 1) Use of global access to Webware with mod_webkit and httpd.conf > referring a path such as /WK to Webware. > > 2) Use of global access to Webware/PSP with mod_webkit and > httpd.conf redirecting .psp pages to Webware. However this > does not currently work with PSP documents under ~user > locations. > > 3) Localized access where the .htaccess file redirects references > through the webkit-handler. Requires mod_webkit be installed > globally in httpd.conf but allows .htaccess references to > unique Webware AppServer by specifying the port to use. Note > that this may currently have problems with ~user expansion too. > > 4) Localized access to PSP through psp-handler references > in .htaccess file. Requires mod_webkit be installed globally > but allows .htaccess to reference a unique AppServer instance > by specifying the port to use. Note that this is broken > currently when using ~user expansion, but a fix is in the works. > > 5) Access through WebKit.cgi. I am not clear of the issues here > but believe there may be some problems with ~user expansion > here as well. > > 6) Access through OneShot.cgi > > The options 1 and 2 above seem to be common. However I believe that the > other options also have value, especially if an ISP wants to offer > Webware, > and allow users to reference their own instance of Webware. > The problems I pointed out with the ~user expansion tell me that > currently, > not many people are trying to use it in that type of an environment. > But I > think the potential for large scale use there is high. > > I think it would be useful for the descriptions of setting up the > environment to outline the various ways in which Webware can be > invoked, and > provide a brief description. > > Also, given the discussions around referencing python vs python2, and > the > requirement for python2, I think this should be clearly addressed. > Unfortunately some distro's (RedHat) have "python" invoking python 1.5.2 > still. That will cause problems for someone unless we automagically > fix it > to reference python2. > > -Stuart- |
From: Frank B. <fb...@fo...> - 2002-12-27 13:21:46
|
Hi, Ian Bicking wrote: > installation, but in a non-complete manner. In my opinion, only > mod_webkit and wkcgi are worth introducing (though I haven't used Please forgive my ignorance, but what is "wkcgi"? I cannot find it in the InstallGuide. Or is it shorthand for WebKit.cgi? ciao -- Frank Barknecht |
From: Ian B. <ia...@co...> - 2002-12-27 20:45:05
|
On Friday, December 27, 2002, at 07:21 AM, Frank Barknecht wrote: > Hi, > Ian Bicking wrote: >> installation, but in a non-complete manner. In my opinion, only >> mod_webkit and wkcgi are worth introducing (though I haven't used > > Please forgive my ignorance, but what is "wkcgi"? I cannot find it in > the > InstallGuide. Or is it shorthand for WebKit.cgi? > It's the C version of the CGI adapter. It's equivalent to WebKit.cgi, but because it's written in C it is far faster. In casual testing a long time ago, it was as fast as the ModPythonAdapter, but far easier to install because it's just a CGI script. It's in WebKit/Adapters/wkcgi -- someone has also compiled it for Windows, which is easier than getting Python scripts to run in that environment (especially under IIS). Ian |
From: Frank B. <fb...@fo...> - 2002-12-28 12:28:23
|
Hi, Ian Bicking schrieb: > It's the C version of the CGI adapter. It's equivalent to WebKit.cgi, > but because it's written in C it is far faster. In casual testing a > long time ago, it was as fast as the ModPythonAdapter, but far easier to > install because it's just a CGI script. It's in > WebKit/Adapters/wkcgi -- someone has also compiled it for Windows, which > is easier than getting Python scripts to run in that environment Cool. I just replaced all WebKit.cgi on my sites, and it works fine and fast ;) I think, it should be made more prominent in the InstallGuide. I skipped the WebKit.exe part, because I thought, that was only valid for W32-systems. ciao -- Frank Barknecht |