From: Olivier FAVRE-S. <oli...@cl...> - 2005-03-10 19:31:27
Attachments:
signature.asc
|
For what it's worth I'm happy to share my way to use Cheetah with Webware. Comments are welcome. Starting with some facts: 1. The only way to have powerfull but well-structured Cheetah templates is to use inheritance (#extends). 2. The only way to have FormKit (or any other form kit that rely on Webware actions) whitout manually tweaking original source code is to inherit from WebKit.Page 3. Cheetah.Template and WebKit.Page do not mix well (at least in current versions) 4. I don't like the "inheritance" approach described in the Cheetah User's Guide: I'm not a templar of the MVC church but a class hierarchy with logic and view classes being intermixed seems ugly and quite to me: Template <--- SiteLogic.py <--- Site.tmpl/.py <--- PageLogic.py <--- Page.tmpl/.py <--- SecurePageLogic.py <--- LoginPageLogic.py <--- LoginPage.tmpl/.py So I came to this design: Since templates are single inheritance only (only one base class, with Template at the root), and I don't want intermixed logic/view classes, let's *** have 2 class hierarchies: one for logic, one for views *** : WebKit.Page <-------------------+---SitePage.py <------+------ Main.py | | MiscUtils.Configurable <--+ +------ ... other public pages | +------ SecurePage.py <-------+------ Login.py | +------ Music.py | +------ ... other 'login required' pages SitePageView.tmpl <------+------ MainView.tmpl | +------ LoginView.tmpl | +------ MusicView.tmpl Each Page in the site will instantiate the corresponding View as self.tmpl in its __init__() method. The .py View has been previously generated from the .tmpl via "cheetah compile" and a Makefile. The searchList is [self], so the template can access all attributes the same way it's done in the documented "inheritance approach". The SitePage class defines 2 methods that subclasses may override: - get_data() to gather all page data (i.e. the controler / business logic) : Obviously must be redefined because each page has a different content - write_html() to generate page content (i.e. the view) : Most a the time the default is sufficient : write the HTML via str(self.tmpl) Because all pages are Webkit pages rather than Cheetah templates it is possible to use FormKit for the Login page and let Webware actions handle the form. ==================================================== class SitePage(Page, Configurable): def __init__(self): Page.__init__(self) Configurable.__init__(self) from SitePageView import SitePageView self.tmpl = SitePageView(searchList=[self]) def writeHTML(self): self.get_data() self.write_html() def write_html(self): self.writeln(str(self.tmpl)) ### etc. other SitePage methods ### ==================================================== class SecurePage(SitePage): def __init__(self): SitePage.__init__(self) def awake(self, trans): SitePage.awake(self,trans) # pseudo-code here: use session() + database query to check login data if ## session invalid / expired## : trans.response().sendRedirect('Login') ### etc. other SecurePage methods ### ==================================================== class Login(FormKitMixIn, SecurePage): def __init__(self): SecurePage.__init__(self) f = self.form = Form.Form(validators=[PasswordValidator(self)]) self.addForm( f ) f.addField( Fields.TextField('username', [Validators.MinLength(5)])) f.addField( Fields.PasswordField('password', [Validators.NotEmpty()])) f.addField( Fields.WebKitSubmitButton(name="submit", label="Log in")) from LoginView import LoginView self.tmpl = LoginView(searchList=[self]) def get_data(self): SecurePage.get_data(self) self.login_form_html = self.form.dump() #login_form_html is a place holder for the whole form in LoginView.tmpl if not self.form.isSuccessful() and self.form.error(): # add form error msg self.login_form_html = self.login_form_html + '<p style="color:red;">%s</p>' % self.form.error() def actions(self): """Form actions - standard WebKit stuff""" return ['submit'] def submit(self): """action for submit button : save user info and redirect to requested page (default: Main) if login successful.""" if self.form.isSuccessful(): self.session().setValue('user', self.userid) self.session().setValue('username', self.form.username) self.response().sendRedirect(self.request().field('page', 'Main')) ### etc. other Login methods ### ==================================================== class Music(SecurePage): def __init__(self): SecurePage.__init__(self) from MusicView import MusicView self.tmpl = MusicView(searchList=[self]) def get_data(self): '''A simple pusic page for the example: display all songs that starts with a given letter in a music files directory.''' SecurePage.get_data(self) self.letter = self.request().field('letter','A') DIR = '/mnt/disk/music' from string import upper from path import path d = path(DIR) self.music_files = [i.name for i in d.listdir() if upper(i.name).startswith(upper(self.letter))] #music_files is a place holder for MusicView.tmpl, wich will iterate (e.g. #for $f in $music_files) to display ### etc. other Music methods ### To make it short what is needed for a new page is: 1. Instantiate the correct view in __init__() 2. Override get_data() to generate content 3. Provide the template for the view On the negative side, the views must have been previously generated from the .tmpl via "cheetah compile"; I've not found a way to have a servlet instantiated template being dynamically compiled when it #extends another template. With the help of a little Makefile: VIEWS=SitePageView.py LoginView.py MusicView.py .SUFFIXES: .py .tmpl all: $(VIEWS) LoginView.tmpl: SitePageView.py Login.py: LoginView.py MusicView.tmpl: SitePageView.py Music.py: MusicView.py clean: rm -f *.pyc rm -f *.py.bak rm -f $(VIEWS) .PHONY: all clean .tmpl.py: @cheetah compile $< I've been using python for some time now, mainly for PyGTK desktop GUI's or XMLRPC/SOAP web services, but for pure web development I'm coming from a PHP/Smarty background. PHP is good for rapid prototyping but on the long-term it's all spaghetti code with screens "pulling" the data from databases. Rails is really cool but it's Ruby ;-) I'ts a pity for me to see that python (IMHO the best language whatever the domain you're working in) has 10 or so web frameworks with as many template engines. That's too many brainpower dissipated in duplicate endeavours. PHP and Rails are strong because the whole community agreed that choosing a "main" (in not single) framework was more important than any technical argument/point of view/limitation/whatever. If we want python to *really* make it on web servers (I mean as an opensource initiative, not Zope), the only way to succeed is (by priority order): 1. Stop/refrain from developping new features when the existing codebase is so poorly documented. (Microsoft MFC and .NET are crap but the documentation is really impressing and make it possible to start from scratch in very little time) 2. Add many examples and a real tutorial. What I mean is that one must not have to copy/paste from html pages to have a running tutorial site. We should have say a webware-examples.tar.bz2: just unpack it in some /opt or /var/www directory, tweak httpd.conf a little and it must be running from scratch). 3. Clearly an non-ambiguously define which packages are prefered and which are deprecated: e.g. Many people advocate SQLObject for Rails-alike sites (which I agree), but nowhere is it clearly defined that one must choose SQLObject over MiddleKit, say for new sites. e.g. I completely failed to understand what UserKit is meant for and how to use it; googling about it did not return valuable info or a good example. 4. Release early release often: The only thing that stops me to actually put big Webware sites on the corporate servers in the company i'm working for is seeing that same 0.8.1 version for so long. I know that development is still going on: I'm regularly updating my development box from ano...@cv... webware module but any serious management will throw me away if I ever speak of a CVS version on a prod server (even a tiny one). Trust matters, and the best way to ensure trust is to *show* that things evolve; knowing it is not sufficient. What we need is JOINING FORCES (and not only in Webware+Cheetah; other web frameworks (heho Aquarium) have common needs/requirements: form handling, session management, etc. Regards. OFS. |
From: Winston W. <win...@ca...> - 2005-03-10 23:03:29
|
I absolutely agree with your comments at the bottom about the state of web frameworks with python. It's not clear to me how to organize it to make it happen though, other than to keep stating it until everyone agrees. Especially, I wish we had more Webware releases. I suppose I could just do it myself, but I feel I don't really know enough yet. -ww On Mar 10, 2005, at 2:38 PM, Olivier FAVRE-SIMON wrote: > > For what it's worth I'm happy to share my way to use Cheetah with > Webware. Comments are welcome. > > > Starting with some facts: > > 1. The only way to have powerfull but well-structured Cheetah > templates is to use inheritance (#extends). > > 2. The only way to have FormKit (or any other form kit that rely on > Webware actions) whitout manually tweaking original source code is to > inherit from WebKit.Page > > 3. Cheetah.Template and WebKit.Page do not mix well (at least in > current versions) > > 4. I don't like the "inheritance" approach described in the Cheetah > User's Guide: I'm not a templar of the MVC church but a class > hierarchy with logic and view classes being intermixed seems ugly and > quite to me: > > Template <--- SiteLogic.py <--- Site.tmpl/.py <--- PageLogic.py <--- > Page.tmpl/.py <--- SecurePageLogic.py <--- LoginPageLogic.py <--- > LoginPage.tmpl/.py > > > > So I came to this design: > > Since templates are single inheritance only (only one base class, with > Template at the root), and I don't want intermixed logic/view classes, > let's > *** have 2 class hierarchies: one for logic, one for views *** : > > > WebKit.Page <-------------------+---SitePage.py <------+------ Main.py > | > | > MiscUtils.Configurable <--+ +------ ... > other public pages > > | > > +------ SecurePage.py <-------+------ Login.py > > | > > +------ Music.py > > | > > +------ ... other > 'login required' pages > > SitePageView.tmpl <------+------ MainView.tmpl > | > +------ LoginView.tmpl > | > +------ MusicView.tmpl > > > Each Page in the site will instantiate the corresponding View as > self.tmpl in its __init__() method. > > The .py View has been previously generated from the .tmpl via "cheetah > compile" and a Makefile. > > The searchList is [self], so the template can access all attributes > the same way it's done in the documented "inheritance approach". > > > The SitePage class defines 2 methods that subclasses may override: > - get_data() to gather all page data (i.e. the controler / business > logic) : Obviously must be redefined because each page has a different > content > - write_html() to generate page content (i.e. the view) : Most a the > time the default is sufficient : write the HTML via str(self.tmpl) > > Because all pages are Webkit pages rather than Cheetah templates it is > possible to use FormKit for the Login page and let Webware actions > handle the form. > > > ==================================================== > class SitePage(Page, Configurable): > > def __init__(self): > > Page.__init__(self) > Configurable.__init__(self) > > from SitePageView import SitePageView > self.tmpl = SitePageView(searchList=[self]) > > def writeHTML(self): > > self.get_data() > self.write_html() > > def write_html(self): > > self.writeln(str(self.tmpl)) > > ### etc. other SitePage methods ### > > > ==================================================== > class SecurePage(SitePage): > > def __init__(self): > SitePage.__init__(self) > > def awake(self, trans): > SitePage.awake(self,trans) > # pseudo-code here: use session() + database query to > check login data > if ## session invalid / expired## : > trans.response().sendRedirect('Login') > > ### etc. other SecurePage methods ### > > > ==================================================== > class Login(FormKitMixIn, SecurePage): > > def __init__(self): > > SecurePage.__init__(self) > > f = self.form = > Form.Form(validators=[PasswordValidator(self)]) > > self.addForm( f ) > > f.addField( Fields.TextField('username', > [Validators.MinLength(5)])) > f.addField( Fields.PasswordField('password', > [Validators.NotEmpty()])) > f.addField( Fields.WebKitSubmitButton(name="submit", > label="Log in")) > > from LoginView import LoginView > self.tmpl = LoginView(searchList=[self]) > > def get_data(self): > > SecurePage.get_data(self) > > self.login_form_html = self.form.dump() > #login_form_html is a place holder for the whole form in > LoginView.tmpl > > if not self.form.isSuccessful() and self.form.error(): > # add form error msg > self.login_form_html = self.login_form_html + > '<p style="color:red;">%s</p>' % self.form.error() > > def actions(self): > """Form actions - standard WebKit stuff""" > return ['submit'] > > def submit(self): > """action for submit button : save user info and > redirect to requested page (default: Main) if login successful.""" > > if self.form.isSuccessful(): > self.session().setValue('user', self.userid) > self.session().setValue('username', > self.form.username) > > self.response().sendRedirect(self.request().field('page', 'Main')) > > ### etc. other Login methods ### > > ==================================================== > class Music(SecurePage): > > def __init__(self): > > SecurePage.__init__(self) > > from MusicView import MusicView > self.tmpl = MusicView(searchList=[self]) > > def get_data(self): > '''A simple pusic page for the example: display all > songs that starts with a given letter in a music files directory.''' > SecurePage.get_data(self) > self.letter = self.request().field('letter','A') > DIR = '/mnt/disk/music' > from string import upper > from path import path > d = path(DIR) > self.music_files = [i.name for i in d.listdir() if > upper(i.name).startswith(upper(self.letter))] > #music_files is a place holder for MusicView.tmpl, wich > will iterate (e.g. #for $f in $music_files) to display > > ### etc. other Music methods ### > > > > > > To make it short what is needed for a new page is: > > 1. Instantiate the correct view in __init__() > 2. Override get_data() to generate content > 3. Provide the template for the view > > > On the negative side, the views must have been previously generated > from the .tmpl via "cheetah compile"; I've not found a way to have a > servlet instantiated template being dynamically compiled when it > #extends another template. > > With the help of a little Makefile: > > VIEWS=SitePageView.py LoginView.py MusicView.py > > .SUFFIXES: .py .tmpl > > all: $(VIEWS) > > LoginView.tmpl: SitePageView.py > Login.py: LoginView.py > > MusicView.tmpl: SitePageView.py > Music.py: MusicView.py > > clean: > rm -f *.pyc > rm -f *.py.bak > rm -f $(VIEWS) > > .PHONY: all clean > > .tmpl.py: > @cheetah compile $< > > > > > > I've been using python for some time now, mainly for PyGTK desktop > GUI's or XMLRPC/SOAP web services, but for pure web development I'm > coming from a PHP/Smarty background. > > PHP is good for rapid prototyping but on the long-term it's all > spaghetti code with screens "pulling" the data from databases. Rails > is really cool but it's Ruby ;-) > > I'ts a pity for me to see that python (IMHO the best language whatever > the domain you're working in) has 10 or so web frameworks with as many > template engines. That's too many brainpower dissipated in duplicate > endeavours. PHP and Rails are strong because the whole community > agreed that choosing a "main" (in not single) framework was more > important than any technical argument/point of > view/limitation/whatever. > > If we want python to *really* make it on web servers (I mean as an > opensource initiative, not Zope), the only way to succeed is (by > priority order): > > 1. Stop/refrain from developping new features when the existing > codebase is so poorly documented. (Microsoft MFC and .NET are crap but > the documentation is really impressing and make it possible to start > from scratch in very little time) > > 2. Add many examples and a real tutorial. What I mean is that one must > not have to copy/paste from html pages to have a running tutorial > site. We should have say a webware-examples.tar.bz2: just unpack it in > some /opt or /var/www directory, tweak httpd.conf a little and it must > be running from scratch). > > 3. Clearly an non-ambiguously define which packages are prefered and > which are deprecated: e.g. Many people advocate SQLObject for > Rails-alike sites (which I agree), but nowhere is it clearly defined > that one must choose SQLObject over MiddleKit, say for new sites. e.g. > I completely failed to understand what UserKit is meant for and how to > use it; googling about it did not return valuable info or a good > example. > > 4. Release early release often: The only thing that stops me to > actually put big Webware sites on the corporate servers in the company > i'm working for is seeing that same 0.8.1 version for so long. I know > that development is still going on: I'm regularly updating my > development box from ano...@cv... webware module but > any serious management will throw me away if I ever speak of a CVS > version on a prod server (even a tiny one). > > Trust matters, and the best way to ensure trust is to *show* that > things evolve; knowing it is not sufficient. > > > > What we need is JOINING FORCES (and not only in Webware+Cheetah; other > web frameworks (heho Aquarium) have common needs/requirements: form > handling, session management, etc. > > > Regards. > > > OFS. > > _________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by creating |
From: Olivier FAVRE-S. <oli...@cl...> - 2005-03-11 00:55:11
Attachments:
signature.asc
|
And I don't myself pretend to have *today* sufficient knowledge of Webware to be at the lead of a major move. But then I must admit it is a vicious endless circle : No concrete example or tutorial for beginners, insufficient docs => less people interested in Webware => less docs and tutorials because the other people have learned the hard way (OK not so hard we all love writing/reading python code) so they dont feel it necessary to write docs... Just a simple example, that stunned me when I started with Webware: image servlets. In PHP nothing is simpler than having a .php script returning a PNG image for use as source inside and HTML IMG tag => dynamicaly generated images. Googling on the subject returns tenth of pages of PHP+GD samples. With webware the only actually working examples are found in *mailing lists*. There is not even one html page looking as a tutorial on the subject. Now assuming that we use actual files for storing images instead of having them returned via content-type image/png. Is it possible to have a per-user-session temporary directory under Sessions, where we would happily store all those temp images, and have the session handling engine automgically delete them on logout ? docs => nothing google => nothing Every example related to sessions in Webware is for storing values. There is no documentation about doing your custom session store (and the cases where you'll need). But I cannot say "you can't have a per-session temp dir" because it's not clearly stated => I end up reading the code again. For people like me that like both python and the webware has having superior design and elegance over PHP, it's quite frustrating not being able to make the move from PHP to webware on bigger sites that our development servers : The management is afraid (with valid reasons) that it will be costly/hazardous to succeed making people having same/superior knowledge in this framework as in PHP. Without the core developers / old warriors making the first move and feeding the community with better docs, most of the wanna-be-python-webware-hackers (like me today) will either stall at their current knowledge level, each using it's own custom and unique approach over and over again, or will resign and move to some more user-friendly framework. Maybe the first steps could be : - Have a site with "doc requests" like the feature requests often found for development. - A kind of Webware Wiki/devcenter where everyone could contribute, like codeproject.com or codeguru.com for the Win32 guys (We run webware on Gentoo Linux but in my all-day work I have many parts to make in Win32/Windoz and these kind of sites prove to be valuable for providing examples on almost all common tasks you encouter in Win32 dev). OFS. Winston Wolff wrote: > I absolutely agree with your comments at the bottom about the state of > web frameworks with python. It's not clear to me how to organize it to > make it happen though, other than to keep stating it until everyone > agrees. > > Especially, I wish we had more Webware releases. I suppose I could > just do it myself, but I feel I don't really know enough yet. > > -ww > > On Mar 10, 2005, at 2:38 PM, Olivier FAVRE-SIMON wrote: > > > For what it's worth I'm happy to share my way to use Cheetah with > Webware. Comments are welcome. > > > Starting with some facts: > > 1. The only way to have powerfull but well-structured Cheetah > templates is to use inheritance (#extends). > > 2. The only way to have FormKit (or any other form kit that rely > on Webware actions) whitout manually tweaking original source code > is to inherit from WebKit.Page > > 3. Cheetah.Template and WebKit.Page do not mix well (at least in > current versions) > > 4. I don't like the "inheritance" approach described in the > Cheetah User's Guide: I'm not a templar of the MVC church but a > class hierarchy with logic and view classes being intermixed seems > ugly and quite to me: > > Template <--- SiteLogic.py <--- Site.tmpl/.py <--- PageLogic.py > <--- Page.tmpl/.py <--- SecurePageLogic.py <--- LoginPageLogic.py > <--- LoginPage.tmpl/.py > > > > So I came to this design: > > Since templates are single inheritance only (only one base class, > with Template at the root), and I don't want intermixed logic/view > classes, let's > *** have 2 class hierarchies: one for logic, one for views *** : > > > WebKit.Page <-------------------+---SitePage.py <------+------ > Main.py > | | > MiscUtils.Configurable <--+ +------ .... other public pages > | > > +------ SecurePage.py <-------+------ Login.py > | > > +------ Music.py > | > > +------ ... other 'login required' pages > > SitePageView.tmpl <------+------ MainView.tmpl > | > +------ LoginView.tmpl > | > +------ MusicView.tmpl > > > Each Page in the site will instantiate the corresponding View as > self.tmpl in its __init__() method. > > The .py View has been previously generated from the .tmpl via > "cheetah compile" and a Makefile. > > The searchList is [self], so the template can access all > attributes the same way it's done in the documented "inheritance > approach". > > > The SitePage class defines 2 methods that subclasses may override: > - get_data() to gather all page data (i.e. the controler / > business logic) : Obviously must be redefined because each page > has a different content > - write_html() to generate page content (i.e. the view) : Most a > the time the default is sufficient : write the HTML via > str(self.tmpl) > > Because all pages are Webkit pages rather than Cheetah templates > it is possible to use FormKit for the Login page and let Webware > actions handle the form. > > > ==================================================== > class SitePage(Page, Configurable): > > def __init__(self): > > Page.__init__(self) > Configurable.__init__(self) > > from SitePageView import SitePageView > self.tmpl = SitePageView(searchList=[self]) > > def writeHTML(self): > > self.get_data() > self.write_html() > > def write_html(self): > > self.writeln(str(self.tmpl)) > > ### etc. other SitePage methods ### > > > ==================================================== > class SecurePage(SitePage): > > def __init__(self): > SitePage.__init__(self) > > def awake(self, trans): > SitePage.awake(self,trans) > # pseudo-code here: use session() + database query to check login > data > if ## session invalid / expired## : > trans.response().sendRedirect('Login') > > ### etc. other SecurePage methods ### > > > ==================================================== > class Login(FormKitMixIn, SecurePage): > > def __init__(self): > > SecurePage.__init__(self) > > f = self.form = Form.Form(validators=[PasswordValidator(self)]) > > self.addForm( f ) > > f.addField( Fields.TextField('username', [Validators.MinLength(5)])) > f.addField( Fields.PasswordField('password', > [Validators.NotEmpty()])) > f.addField( Fields.WebKitSubmitButton(name="submit", label="Log in")) > > from LoginView import LoginView > self.tmpl = LoginView(searchList=[self]) > > def get_data(self): > > SecurePage.get_data(self) > > self.login_form_html = self.form.dump() #login_form_html is a > place holder for the whole form in LoginView.tmpl > > if not self.form.isSuccessful() and self.form.error(): > # add form error msg > self.login_form_html = self.login_form_html + '<p > style="color:red;">%s</p>' % self.form.error() > > def actions(self): > """Form actions - standard WebKit stuff""" > return ['submit'] > > def submit(self): > """action for submit button : save user info and redirect to > requested page (default: Main) if login successful.""" > > if self.form.isSuccessful(): > self.session().setValue('user', self.userid) > self.session().setValue('username', self.form.username) > > self.response().sendRedirect(self.request().field('page', 'Main')) > > ### etc. other Login methods ### > > ==================================================== > class Music(SecurePage): > > def __init__(self): > > SecurePage.__init__(self) > > from MusicView import MusicView > self.tmpl = MusicView(searchList=[self]) > > def get_data(self): > '''A simple pusic page for the example: display all songs that > starts with a given letter in a music files directory.''' > SecurePage.get_data(self) > self.letter = self.request().field('letter','A') > DIR = '/mnt/disk/music' > from string import upper > from path import path > d = path(DIR) > self.music_files = [i.name for i in d.listdir() if > upper(i.name).startswith(upper(self.letter))] > #music_files is a place holder for MusicView.tmpl, wich will > iterate (e.g. #for $f in $music_files) to display > > ### etc. other Music methods ### > > > > > > To make it short what is needed for a new page is: > > 1. Instantiate the correct view in __init__() > 2. Override get_data() to generate content > 3. Provide the template for the view > > > On the negative side, the views must have been previously > generated from the .tmpl via "cheetah compile"; I've not found a > way to have a servlet instantiated template being dynamically > compiled when it #extends another template. > > With the help of a little Makefile: > > VIEWS=SitePageView.py LoginView.py MusicView.py > > ..SUFFIXES: .py .tmpl > > all: $(VIEWS) > > LoginView.tmpl: SitePageView.py > Login.py: LoginView.py > > MusicView.tmpl: SitePageView.py > Music.py: MusicView.py > > clean: > rm -f *.pyc > rm -f *.py.bak > rm -f $(VIEWS) > > ..PHONY: all clean > > ..tmpl.py: > @cheetah compile $< > > > > > > I've been using python for some time now, mainly for PyGTK desktop > GUI's or XMLRPC/SOAP web services, but for pure web development > I'm coming from a PHP/Smarty background. > > PHP is good for rapid prototyping but on the long-term it's all > spaghetti code with screens "pulling" the data from databases. > Rails is really cool but it's Ruby ;-) > > I'ts a pity for me to see that python (IMHO the best language > whatever the domain you're working in) has 10 or so web frameworks > with as many template engines. That's too many brainpower > dissipated in duplicate endeavours. PHP and Rails are strong > because the whole community agreed that choosing a "main" (in not > single) framework was more important than any technical > argument/point of view/limitation/whatever. > > If we want python to *really* make it on web servers (I mean as an > opensource initiative, not Zope), the only way to succeed is (by > priority order): > > 1. Stop/refrain from developping new features when the existing > codebase is so poorly documented. (Microsoft MFC and .NET are crap > but the documentation is really impressing and make it possible to > start from scratch in very little time) > > 2. Add many examples and a real tutorial. What I mean is that one > must not have to copy/paste from html pages to have a running > tutorial site. We should have say a webware-examples.tar.bz2: just > unpack it in some /opt or /var/www directory, tweak httpd.conf a > little and it must be running from scratch). > > 3. Clearly an non-ambiguously define which packages are prefered > and which are deprecated: e.g. Many people advocate SQLObject for > Rails-alike sites (which I agree), but nowhere is it clearly > defined that one must choose SQLObject over MiddleKit, say for new > sites. e.g. I completely failed to understand what UserKit is > meant for and how to use it; googling about it did not return > valuable info or a good example. > > 4. Release early release often: The only thing that stops me to > actually put big Webware sites on the corporate servers in the > company i'm working for is seeing that same 0.8.1 version for so > long. I know that development is still going on: I'm regularly > updating my development box from ano...@cv... > webware module but any serious management will throw me away if I > ever speak of a CVS version on a prod server (even a tiny one). > > Trust matters, and the best way to ensure trust is to *show* that > things evolve; knowing it is not sufficient. > > > > What we need is JOINING FORCES (and not only in Webware+Cheetah; > other web frameworks (heho Aquarium) have common > needs/requirements: form handling, session management, etc. > > > Regards. > > > OFS. > > > _________________________________________ > winston wolff - (646) 827-2242 - http://www.stratolab.com - learning > by creating > |
From: Eric R. <th...@er...> - 2005-03-11 02:09:44
|
On 02:01 Fri 11 Mar , Olivier FAVRE-SIMON wrote: > > And I don't myself pretend to have *today* sufficient knowledge of > Webware to be at the lead of a major move. > > But then I must admit it is a vicious endless circle : > > No concrete example or tutorial for beginners, insufficient docs => > less people interested in Webware => less docs and tutorials because > the other people have learned the hard way (OK not so hard we all love > writing/reading python code) so they dont feel it necessary to write > docs... While what you say is all quite true, this is the condition of many Python frameworks. I'm sure that most of us have landed on Webware because we thought it was worth the pain of having to dig through mailing list archives for the answers. It's an insane process. > Without the core developers / old warriors making the first move and > feeding the community with better docs, most of the > wanna-be-python-webware-hackers (like me today) will either stall at > their current knowledge level, each using it's own custom and unique > approach over and over again, or will resign and move to some more > user-friendly framework. These are all reasons why documentation is wanting. My projects have been driven by specific requirements, so I've been uneasy about documenting my custom methods, which may not be a pattern for best-practices, but work for what I need the framework to do. > Maybe the first steps could be : > - Have a site with "doc requests" like the feature requests often > found for development. > - A kind of Webware Wiki/devcenter where everyone could contribute, like > codeproject.com or codeguru.com We have a Wiki, so anyone who wants to start something new or audit existing material can do so. You're ideas are good, so I would encourage you to start a how-to section on the Wiki or something similar. Eric Radman |
From: Warren S. <wa...@wa...> - 2005-03-11 13:37:43
|
Olivier FAVRE-SIMON said: > *** have 2 class hierarchies: one for logic, one for views *** : This is exactly the approach that I have taken as well. Keeping the presentation in a separate hierarchy makes the code much cleaner and completely sidesteps the multiple inheritance issues with Cheetah, Webkit.Page, and FormKit. > What we need is JOINING FORCES (and not only in Webware+Cheetah; other > web frameworks (heho Aquarium) have common needs/requirements: form > handling, session management, etc. > I totally agree, though I suspect it is much easier said than done. I suspect most of the frameworks exist because their main developer "scratched his own itch". Sometimes it is easier to just re-invent the wheel than deal with the community that already invented it in order to get your issues with it resolved. I suppose that some of them exist because the author's were just not aware of the alternatives due to a lack of exposure. Webware is fortunate that it has had the exposure it has had. Unfortunately, that exposure is a two-edged sword. If, when people DO find the project, what do they think when they look at it right now? Webware has a serious "image" problem in my opinion. The new web site is a step in the right direction, but a production quality release (version 1.0) is LONG overdue. Unfortunately, I cannot contribute as much as I would like to the Webware development process, so it is hard for me be too critical of the Webware developers. I suspect that many of the developers are in a similar situation (too busy USING the tool to make a living to have time to IMPROVE the tool). Perhaps if I was able to use Webware at work, I would be able to spend time giving back to the project. But alas, the corporate mindset where I work has dictated that our product, which is currently implemented in Python CGI, will be re-written under J2EE. Even if Python was approved for continued development, I think I would have a hard time convincing management to commit to Webware without some significant changes to Webware's apparent stability/maturity and percieved development status. There would also have to be some changes to Webkit to make it scale across multiple machines. Our CGI application currently runs on 13 web servers behind an IP sprayer. Moving to a long-running process like Webkit would make it much more efficient. However, we would still need it to work cleanly on more than one app-server. The issue of sharing session data between app-servers is probably the largest issue that would need to be resolved. My experience with Webkit so far has been that it is not designed with this type of environment in mind, though I don't think it wouldn't take much to fix it. It is interesting that you mention Aquarium. I had not heard of it until yesterday. I had a phone interview yesterday evening with Iron-Port Systems in San Bruno, CA and the interviewer saw that I had used Webware and suggested I look at Aquarium. I have not had time to do more than browse the web site, but so far I am impressed, especially with what appears to be the comprehensive API documentation. It appears that the Aquarium project was initiated around the same time as as Webware and has had a similar number of releases. The big difference is that Aquarium is currently at version 2.1, as opposed to Webware's 0.8.1. Now I know that version numbers don't mean much from a technical standpoint, but when trying to convince management to commit to a web development platform, I would expect that having to justify Webware's "beta" state does not look good. Having to explain why Webware has not had a release in over 18 months probably doesn't look good either. Perhaps somebody with real experience in this area can coroberate or refute my suspicions. From a purely technical perspective, I have been quite pleased with Webkit's advantages over CGI and have enjoyed writing the few Webkit-based applications I have been able to write in my spare time. I think that Webware's "image" problems can be easily solved, but it is going to take a concerted, coordinated effort by the Webware community to pull it off. Someone with sufficient time and expertise needs to take the lead and do whatever it takes to get a "production" release of webware out ASAP. It would be a shame for Webware to lose the mind-share it has taken so long to acquire. I would be willing to contribute where I can. Perhaps I can work some more on DbConnectionPool.py (http://cvs.sourceforge.net/viewcvs.py/webware-sandbox/Sandbox/wsmith323/DbConnectionPool.py?rev=1.18&view=log) and get it to what I would consider a stable, production ready state. I'll see what I can do. Meanwhile, I am going to give Aquarium a serious look. Perhaps my issues with Webware have already been addressed in a different framework. If so, it may be hard for me to justify the effort to help Webware. We'll see... -- Warren Smith wa...@wa... |
From: Aaron S. <aa...@ne...> - 2005-03-11 14:17:36
|
I just wanted to mention, since it's been brought up, that I have taken the time integrate Pyro (pyro.sourceforge.net) into Webware for the purpose of spaning Webware across multiple machines. I have a rough version already in production use, where I have three inter-linked applications running under seperate Webware instances but sharing the Session store through Pyro. The applications are also able to expose APIs in the form of Pyro Servlets (as opposed to HTTP Servlets) and to trade arbitrary objects (Pyro supports the transfer of code for an unknown object from server to client). I've been planning to clean-up the code and submit it to the community for a while, but have been holding off for a couple of reasons. I have just finish a major 4 month build out so I believe that I will have time this month to extract the code from the more application specific stuff. I just don't want to get in the way of a new release which is the most important thing for Webware right now IMHO. If there is a lot of interest in this, I may even make the time next week. - Aaron On Fri, 2005-03-11 at 08:37, Warren Smith wrote: > Olivier FAVRE-SIMON said: > > *** have 2 class hierarchies: one for logic, one for views *** : > > This is exactly the approach that I have taken as well. Keeping the > presentation in a separate hierarchy makes the code much cleaner and > completely sidesteps the multiple inheritance issues with Cheetah, > Webkit.Page, and FormKit. > > > What we need is JOINING FORCES (and not only in Webware+Cheetah; other > > web frameworks (heho Aquarium) have common needs/requirements: form > > handling, session management, etc. > > > > I totally agree, though I suspect it is much easier said than done. I > suspect most of the frameworks exist because their main developer > "scratched his own itch". Sometimes it is easier to just re-invent the > wheel than deal with the community that already invented it in order to > get your issues with it resolved. I suppose that some of them exist > because the author's were just not aware of the alternatives due to a lack > of exposure. Webware is fortunate that it has had the exposure it has > had. Unfortunately, that exposure is a two-edged sword. If, when people > DO find the project, what do they think when they look at it right now? > Webware has a serious "image" problem in my opinion. The new web site is > a step in the right direction, but a production quality release (version > 1.0) is LONG overdue. > > Unfortunately, I cannot contribute as much as I would like to the Webware > development process, so it is hard for me be too critical of the Webware > developers. I suspect that many of the developers are in a similar > situation (too busy USING the tool to make a living to have time to > IMPROVE the tool). Perhaps if I was able to use Webware at work, I would > be able to spend time giving back to the project. But alas, the corporate > mindset where I work has dictated that our product, which is currently > implemented in Python CGI, will be re-written under J2EE. Even if Python > was approved for continued development, I think I would have a hard time > convincing management to commit to Webware without some significant > changes to Webware's apparent stability/maturity and percieved development > status. There would also have to be some changes to Webkit to make it > scale across multiple machines. Our CGI application currently runs on 13 > web servers behind an IP sprayer. Moving to a long-running process like > Webkit would make it much more efficient. However, we would still need it > to work cleanly on more than one app-server. The issue of sharing session > data between app-servers is probably the largest issue that would need to > be resolved. My experience with Webkit so far has been that it is not > designed with this type of environment in mind, though I don't think it > wouldn't take much to fix it. > > It is interesting that you mention Aquarium. I had not heard of it until > yesterday. I had a phone interview yesterday evening with Iron-Port > Systems in San Bruno, CA and the interviewer saw that I had used Webware > and suggested I look at Aquarium. I have not had time to do more than > browse the web site, but so far I am impressed, especially with what > appears to be the comprehensive API documentation. It appears that the > Aquarium project was initiated around the same time as as Webware and has > had a similar number of releases. The big difference is that Aquarium is > currently at version 2.1, as opposed to Webware's 0.8.1. Now I know that > version numbers don't mean much from a technical standpoint, but when > trying to convince management to commit to a web development platform, I > would expect that having to justify Webware's "beta" state does not look > good. Having to explain why Webware has not had a release in over 18 > months probably doesn't look good either. Perhaps somebody with real > experience in this area can coroberate or refute my suspicions. > > >From a purely technical perspective, I have been quite pleased with > Webkit's advantages over CGI and have enjoyed writing the few Webkit-based > applications I have been able to write in my spare time. I think that > Webware's "image" problems can be easily solved, but it is going to take a > concerted, coordinated effort by the Webware community to pull it off. > Someone with sufficient time and expertise needs to take the lead and do > whatever it takes to get a "production" release of webware out ASAP. It > would be a shame for Webware to lose the mind-share it has taken so long > to acquire. > > I would be willing to contribute where I can. Perhaps I can work some > more on DbConnectionPool.py > (http://cvs.sourceforge.net/viewcvs.py/webware-sandbox/Sandbox/wsmith323/DbConnectionPool.py?rev=1.18&view=log) > and get it to what I would consider a stable, production ready state. > I'll see what I can do. > > Meanwhile, I am going to give Aquarium a serious look. Perhaps my issues > with Webware have already been addressed in a different framework. If so, > it may be hard for me to justify the effort to help Webware. > > We'll see... |
From: Ian B. <ia...@co...> - 2005-03-15 21:51:52
|
Warren Smith wrote: > Unfortunately, I cannot contribute as much as I would like to the Webware > development process, so it is hard for me be too critical of the Webware > developers. I suspect that many of the developers are in a similar > situation (too busy USING the tool to make a living to have time to > IMPROVE the tool). Perhaps if I was able to use Webware at work, I would > be able to spend time giving back to the project. But alas, the corporate > mindset where I work has dictated that our product, which is currently > implemented in Python CGI, will be re-written under J2EE. Even if Python > was approved for continued development, I think I would have a hard time > convincing management to commit to Webware without some significant > changes to Webware's apparent stability/maturity and percieved development > status. There would also have to be some changes to Webkit to make it > scale across multiple machines. Our CGI application currently runs on 13 > web servers behind an IP sprayer. Moving to a long-running process like > Webkit would make it much more efficient. However, we would still need it > to work cleanly on more than one app-server. The issue of sharing session > data between app-servers is probably the largest issue that would need to > be resolved. My experience with Webkit so far has been that it is not > designed with this type of environment in mind, though I don't think it > wouldn't take much to fix it. I'm coming in a bit late on this, but wouldn't a database-backed session be the easiest way to implement shared sessions? Hrm... I thought Webware actually included such a thing; but anyway, it seems very easy to implement, could be based 100% on the DB-API and primitive SQL (avoiding database compatibility issues and other dependencies), and would be a nice, reasonably scalable shared session. And we all have databases of one sort or another (at least if we're worried about this kind of scaling), so it seems like an easy solution. SessionFileStore would probably be the simplest example to base this on. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Huy <hu...@sw...> - 2005-03-11 15:13:12
|
> PHP and Rails are strong because the whole community agreed > that choosing a "main" (in not single) framework was more important than > any technical argument/point of view/limitation/whatever. Is Rails strong ? I've looked at it and have not been that impressed. I've written a code generator for webware + cheetah (using cheetah) 2 years ago to do all this stuff. What's the big deal ! The crud stuff is always the easiest thing to do anyway. The business logic has always been the main challenge in all the applications I've been involved with regardless of language or platform. > 3. Clearly an non-ambiguously define which packages are prefered and > which are deprecated: e.g. Many people advocate SQLObject for > Rails-alike sites (which I agree), but nowhere is it clearly defined > that one must choose SQLObject over MiddleKit, say for new sites. e.g. I > completely failed to understand what UserKit is meant for and how to use > it; googling about it did not return valuable info or a good example. My only advice is, ff you don't know what it's used for, don't use it. That would go for anything really. If you can't think of why SQLObject should not be used instead of MiddleKit then just use SQLObject. You guys need to make certain decisions on your own. All the information is out there to make your own judgements. > 4. Release early release often: The only thing that stops me to actually > put big Webware sites on the corporate servers in the company i'm > working for is seeing that same 0.8.1 version for so long. I know that > development is still going on: I'm regularly updating my development box > from ano...@cv... webware module but any serious > management will throw me away if I ever speak of a CVS version on a prod > server (even a tiny one). > > Trust matters, and the best way to ensure trust is to *show* that things > evolve; knowing it is not sufficient. > Generally evolution is important but so is simplicity. I've been involved with two projects using a 20year old 4GL to write cgi programs serving hundreds of users across multiple countries. Both projects were huge successes (we're talking big bucks) and still are running today and hopefully for many years to come. The moral of this story, if I can write it in this 4GL, believe me I could have done a much better job in Webware (and Python if I new about it 5 years ago) so I'm definitely not complaining. Ohh and by the way, whoever said CGI was not scaleable was talking out of their ass. Huy |
From: Warren S. <wa...@wa...> - 2005-03-11 15:54:09
|
Huy said: > always the easiest thing to do anyway. The business logic has always > been the main challenge in all the applications I've been involved with > regardless of language or platform. > I would agree here. The lion's share of work is always in actually using the tools. Judicious time spent improving the tools can help significantly, but at some point you have to put on the "I've got to get this thing done regardless of how elegant it is" hat and get to work on what really matters to the client. > My only advice is, ff you don't know what it's used for, don't use it. > That would go for anything really. If you can't think of why SQLObject > should not be used instead of MiddleKit then just use SQLObject. You > guys need to make certain decisions on your own. All the information is > out there to make your own judgements. > I agree. One of the things I like about Webware is that it doesn't (for the most part) *force* you to use tool A because you are using tool B, unlike some other Python frameworks (cough...cough...Zope). On the other hand, it would be nice if those who are using the various tools contributed their knowledge back to the community in a more formalized and organized fashion than just posts to the mailing list (wiki anyone ?). However, I can't be too critical because I am just as guilty as the next person. > complaining. Ohh and by the way, whoever said CGI was not scaleable was > talking out of their ass. > I'm not sure if this was directed at me or not. If so, I didn't mean to imply that CGI was not scalable. In fact, we have found that CGI is VERY scalable. Just throw enough hardware at the application and it will scale almost infinitely. That is why we have 13 (albeit small) machines serving one application. The problem we have is request latency. Under the CGI model, we have to be very careful about how much code we are loading on each request. We also have to be very careful to reuse database connections where possible. The code-loading issue leads us to do performance optimization in the form of lazy definition of constants, etc. These optimizations make the code more complicated and less clear than it would be if we had a long-running process that could load the code once and then just *have it* in memory. The database connection reuse issue has been solved by using a pooling mechanizm similar to the DbConnectionPool module that I open-sourced. Still, we have to incure the overhead, on each request, of building the database connection for each database we need to talk to. This overhead can be significant for IBM DB2, which is the database that corporate says we *must* use. Even with our best efforts so far, our request latency is still to high in my opinion. There are more things that we could still do, but the powers-that-be have decided that it is currently "good enough", given our planned move to J2EE. -- Warren Smith wa...@wa... |
From: Olivier FAVRE-S. <oli...@cl...> - 2005-03-11 17:09:15
Attachments:
signature.asc
|
Huy wrote: >> PHP and Rails are strong because the whole community agreed that >> choosing a "main" (in not single) framework was more important than >> any technical argument/point of view/limitation/whatever. > > > Is Rails strong ? I've looked at it and have not been that impressed. > I've written a code generator for webware + cheetah (using cheetah) 2 > years ago to do all this stuff. What's the big deal ! The crud stuff > is always the easiest thing to do anyway. The business logic has > always been the main challenge in all the applications I've been > involved with regardless of language or platform. > I do not mean Rails is actually a *better* tool. I mean it gathers the whole community of Ruby, which leads to more user contributions, with more frequent updates: Rails 0.10 has been released on March 7th; and merged into Gentoo Linux which I use the 10th. That's the kind of fact I would be happy to show with Webware, which I prefer, when debating with developers and my fellow coworkers who defend Ruby and most of the time PHP. >> 3. Clearly an non-ambiguously define which packages are prefered and >> which are deprecated: e.g. Many people advocate SQLObject for >> Rails-alike sites (which I agree), but nowhere is it clearly defined >> that one must choose SQLObject over MiddleKit, say for new sites. >> e.g. I completely failed to understand what UserKit is meant for and >> how to use it; googling about it did not return valuable info or a >> good example. > > > My only advice is, ff you don't know what it's used for, don't use it. > That would go for anything really. If you can't think of why SQLObject > should not be used instead of MiddleKit then just use SQLObject. You > guys need to make certain decisions on your own. All the information > is out there to make your own judgements. > I think I know what it's used for ;-). Personnaly I use either SQLObject for simple query, because I like the elegant model of ORMs, or "raw" MySQLdb when I think it will be more efficient (i.e. SQLObject would make more calls to DBMS to achieve the same result). But even if I.Bicking a known and respected figure in the python community, MiddleKit is always the reference tool on the official webware4python site. >> 4. Release early release often: The only thing that stops me to >> actually put big Webware sites on the corporate servers in the >> company i'm working for is seeing that same 0.8.1 version for so >> long. I know that development is still going on: I'm regularly >> updating my development box from ano...@cv... >> webware module but any serious management will throw me away if I >> ever speak of a CVS version on a prod server (even a tiny one). > > > > >> Trust matters, and the best way to ensure trust is to *show* that >> things evolve; knowing it is not sufficient. >> > > Generally evolution is important but so is simplicity. I've been > involved with two projects using a 20year old 4GL to write cgi > programs serving hundreds of users across multiple countries. Both > projects were huge successes (we're talking big bucks) and still are > running today and hopefully for many years to come. The moral of this > story, if I can write it in this 4GL, believe me I could have done a > much better job in Webware (and Python if I new about it 5 years ago) > so I'm definitely not complaining. Ohh and by the way, whoever said > CGI was not scaleable was talking out of their ass. > I've myself been working for one the biggest french banking company, so i fully understand what legacy software is. That's the kind of company where you just can't put another other tool/language in the development process (let alone the production servers) whitout a serious motivation and concrete facts. For every honest person there is no doubt that python+Webware is a great tool, but if you look on the long term, the biggest point for decision is the momentum accumulated by the framework you choose Has it gathered a large enough community to be still of some use along the whole planned duration of our projects ? And for CGI I certainly do not spit on it (I didn't even say CGI in my post). Like most of us (i believe) I've started with wkcgi before switching to mod_webkit2. But even if I lack experimenting with Webware long-term running servers, I'm definitely confident about robustness because of the great foundations it's built upon (no MS IIS inetinfo.exe process with 1850MB VM size...), and I will make mod_webkit my 1st choice. > Huy > > OFS. |
From: Olivier FAVRE-S. <oli...@cl...> - 2005-03-11 17:25:49
Attachments:
signature.asc
|
That's great news. I've seen this topic of multiple webware servers with a common=20 sessionstore quite a few times, which is important for=20 robustness/reliability. Do you use session affinity (ie. if you started on server n=B0X you stay=20 on server n=B0X for the the whole duration of the session) or is it=20 already fully distributed amongst all available servers in a pool ? Pyro seems good to me. I've no experience of CORBA or Java RMI, but I'v=20 been using many times .NET Remoting for inter-WindowsServer2003 object=20 remoting, and when I looked for the replacement tool in python I also=20 choosed PyRO but I lacked time to actually do the job (and the remoting=20 servers were running fine already). Aaron Switzer wrote: >I just wanted to mention, since it's been brought up, that I have taken >the time integrate Pyro (pyro.sourceforge.net) into Webware for the >purpose of spaning Webware across multiple machines. I have a rough >version already in production use, where I have three inter-linked >applications running under seperate Webware instances but sharing the >Session store through Pyro. The applications are also able to expose >APIs in the form of Pyro Servlets (as opposed to HTTP Servlets) and to >trade arbitrary objects (Pyro supports the transfer of code for an >unknown object from server to client). > >I've been planning to clean-up the code and submit it to the community >for a while, but have been holding off for a couple of reasons. I have >just finish a major 4 month build out so I believe that I will have time >this month to extract the code from the more application specific >stuff. I just don't want to get in the way of a new release which is >the most important thing for Webware right now IMHO. > >If there is a lot of interest in this, I may even make the time next >week. > >- Aaron > > > >On Fri, 2005-03-11 at 08:37, Warren Smith wrote: > =20 > >>Olivier FAVRE-SIMON said: >> =20 >> >>>*** have 2 class hierarchies: one for logic, one for views *** : >>> =20 >>> >>This is exactly the approach that I have taken as well. Keeping the >>presentation in a separate hierarchy makes the code much cleaner and >>completely sidesteps the multiple inheritance issues with Cheetah, >>Webkit.Page, and FormKit. >> >> =20 >> >>>What we need is JOINING FORCES (and not only in Webware+Cheetah; other >>>web frameworks (heho Aquarium) have common needs/requirements: form >>>handling, session management, etc. >>> >>> =20 >>> >>I totally agree, though I suspect it is much easier said than done. I >>suspect most of the frameworks exist because their main developer >>"scratched his own itch". Sometimes it is easier to just re-invent the >>wheel than deal with the community that already invented it in order to >>get your issues with it resolved. I suppose that some of them exist >>because the author's were just not aware of the alternatives due to a l= ack >>of exposure. Webware is fortunate that it has had the exposure it has >>had. Unfortunately, that exposure is a two-edged sword. If, when peop= le >>DO find the project, what do they think when they look at it right now?= =20 >>Webware has a serious "image" problem in my opinion. The new web site = is >>a step in the right direction, but a production quality release (versio= n >>1.0) is LONG overdue. >> >>Unfortunately, I cannot contribute as much as I would like to the Webwa= re >>development process, so it is hard for me be too critical of the Webwar= e >>developers. I suspect that many of the developers are in a similar >>situation (too busy USING the tool to make a living to have time to >>IMPROVE the tool). Perhaps if I was able to use Webware at work, I wou= ld >>be able to spend time giving back to the project. But alas, the corpor= ate >>mindset where I work has dictated that our product, which is currently >>implemented in Python CGI, will be re-written under J2EE. Even if Pyth= on >>was approved for continued development, I think I would have a hard tim= e >>convincing management to commit to Webware without some significant >>changes to Webware's apparent stability/maturity and percieved developm= ent >>status. There would also have to be some changes to Webkit to make it >>scale across multiple machines. Our CGI application currently runs on = 13 >>web servers behind an IP sprayer. Moving to a long-running process lik= e >>Webkit would make it much more efficient. However, we would still need= it >>to work cleanly on more than one app-server. The issue of sharing sess= ion >>data between app-servers is probably the largest issue that would need = to >>be resolved. My experience with Webkit so far has been that it is not >>designed with this type of environment in mind, though I don't think it >>wouldn't take much to fix it. >> >>It is interesting that you mention Aquarium. I had not heard of it unt= il >>yesterday. I had a phone interview yesterday evening with Iron-Port >>Systems in San Bruno, CA and the interviewer saw that I had used Webwar= e >>and suggested I look at Aquarium. I have not had time to do more than >>browse the web site, but so far I am impressed, especially with what >>appears to be the comprehensive API documentation. It appears that the >>Aquarium project was initiated around the same time as as Webware and h= as >>had a similar number of releases. The big difference is that Aquarium = is >>currently at version 2.1, as opposed to Webware's 0.8.1. Now I know th= at >>version numbers don't mean much from a technical standpoint, but when >>trying to convince management to commit to a web development platform, = I >>would expect that having to justify Webware's "beta" state does not loo= k >>good. Having to explain why Webware has not had a release in over 18 >>months probably doesn't look good either. Perhaps somebody with real >>experience in this area can coroberate or refute my suspicions. >> >>>From a purely technical perspective, I have been quite pleased with >>Webkit's advantages over CGI and have enjoyed writing the few Webkit-ba= sed >>applications I have been able to write in my spare time. I think that >>Webware's "image" problems can be easily solved, but it is going to tak= e a >>concerted, coordinated effort by the Webware community to pull it off.=20 >>Someone with sufficient time and expertise needs to take the lead and d= o >>whatever it takes to get a "production" release of webware out ASAP. I= t >>would be a shame for Webware to lose the mind-share it has taken so lon= g >>to acquire. >> >>I would be willing to contribute where I can. Perhaps I can work some >>more on DbConnectionPool.py >>(http://cvs.sourceforge.net/viewcvs.py/webware-sandbox/Sandbox/wsmith32= 3/DbConnectionPool.py?rev=3D1.18&view=3Dlog) >>and get it to what I would consider a stable, production ready state.=20 >>I'll see what I can do. >> >>Meanwhile, I am going to give Aquarium a serious look. Perhaps my issu= es >>with Webware have already been addressed in a different framework. If = so, >>it may be hard for me to justify the effort to help Webware. >> >>We'll see... >> =20 >> > > > =20 > |
From: Aaron S. <aa...@ne...> - 2005-03-11 19:21:58
|
As it works right now, I have one Webware instance that handles all session information, lets call it WW1. I then have three different applications running under three other Webware instances, lets call them WW2, WW3 and WW4. When a user accesses one of the applications for the first time a session is created for them, through Pyro, on WW1. As they move from one application to the other their session information follows them. Basically it acts as a single sign-on solution. The main limitation with this setup is that if WW1 goes offline for some reason all of the applications go with it. I'm still looking at ways to better distribute the session storage. One idea I have is for each Webware instance to store session information, but when they do they become the "owner" of that session. For example, a user accesses an application on WW2, at which point a session is created for them on WW2. The user then accesses WW3 and through some mechanism WW3 knows that WW2 "owns" the user's session and requests it from WW2. Basically what I've done, and would like to hand over to the community, is the integration of Webware and Pyro. How exactly that integration is used (for session distribution, cross-instance communication, etc.) is pretty much up to the community. As I said before, the current implementation is pretty rough and it's not something that could be immediately dropped into the Webware CVS.=20 What I would like to do is extract the changes I've made to the Webware source and put it somewhere public, like the Webware sandbox, and let anyone who's interested play around with. Then we could start a discussion about the best way to bring it into the main Webware source tree, or whether that should happen at all. As a final note, while doing the integration I went out of my way to only make changes to Webware so that I would only have to maintain changes to one code base. Unfortunately this did lead to some ugly hacks. The most annoying thing to deal with was the fact the Pyro is designed to run under it's own daemon. So to get it working under the=20 Webware AppServer I had to trick Pyro into thinking that it was using it's own daemon without actually having it open a socket.=20 - Aaron On Fri, 2005-03-11 at 12:32, Olivier FAVRE-SIMON wrote: > That's great news. >=20 > I've seen this topic of multiple webware servers with a common=20 > sessionstore quite a few times, which is important for=20 > robustness/reliability. >=20 > Do you use session affinity (ie. if you started on server n=C2=B0X you = stay=20 > on server n=C2=B0X for the the whole duration of the session) or is it=20 > already fully distributed amongst all available servers in a pool ? >=20 >=20 > Pyro seems good to me. I've no experience of CORBA or Java RMI, but I'v= =20 > been using many times .NET Remoting for inter-WindowsServer2003 object=20 > remoting, and when I looked for the replacement tool in python I also=20 > choosed PyRO but I lacked time to actually do the job (and the remoting= =20 > servers were running fine already). >=20 >=20 > Aaron Switzer wrote: >=20 > >I just wanted to mention, since it's been brought up, that I have take= n > >the time integrate Pyro (pyro.sourceforge.net) into Webware for the > >purpose of spaning Webware across multiple machines. I have a rough > >version already in production use, where I have three inter-linked > >applications running under seperate Webware instances but sharing the > >Session store through Pyro. The applications are also able to expose > >APIs in the form of Pyro Servlets (as opposed to HTTP Servlets) and to > >trade arbitrary objects (Pyro supports the transfer of code for an > >unknown object from server to client). > > > >I've been planning to clean-up the code and submit it to the community > >for a while, but have been holding off for a couple of reasons. I hav= e > >just finish a major 4 month build out so I believe that I will have ti= me > >this month to extract the code from the more application specific > >stuff. I just don't want to get in the way of a new release which is > >the most important thing for Webware right now IMHO. > > > >If there is a lot of interest in this, I may even make the time next > >week. > > > >- Aaron |