That's great news.
I've seen this topic of multiple webware servers with a common sessionstore quite a few times, which is important for robustness/reliability.
Do you use session affinity (ie. if you started on server n°X you stay on server n°X for the the whole duration of the session) or is it 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 been using many times .NET Remoting for inter-WindowsServer2003 object remoting, and when I looked for the replacement tool in python I also choosed PyRO but I lacked time to actually do the job (and the remoting 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:
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.
I totally agree, though I suspect it is much easier said than done. IWhat 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.
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 withWebkit'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...
signature.asc
Description: OpenPGP digital signature
