Chuck Esterbrook wrote: > But I was a little surprised that after all the work you recently put > in, you would then immediately outline a roadmap that sounds like "how > to evaporate Webware" at which point its hard to imagine using 1.0 for > anything. I *wasn't* surprised when several unsubscribes followed your > message. If sub 3.0 focuses on removing non-WebKit items and 3.0 gets > rid of the app server, then what is left at the end of the road?
Maybe I did not use the right wording. What I wanted to get across was not "how to evaporate Webware" but "how to keep Webware alive and support exisiting Webware apps as long as possible" given the currently available resources (e.g. mainly my own limited amount of time). Concerning the app server, it will still remain in 1.x and be usable for many years. In 3.x it will not be needed any more, because Webware will then support WSGI and you will be able to connect directly to Apache or any webserver with WSGI suport. And what alternative do we have? WebKit's ThreadedAppServer has hit the wall built by the GIL (which will stay in Py 3.0) on multicore machines. So we would need to develop another MultiProcessAppServer. We'd also need to maintain mod_webkit and the other adapters for our AppServer to make them run with newer Apache versions or modern web servers such as lighttpd, nginx or cherokee. That would be a huge effort and I currently don't see a compelling reason and people supporting this idea. I think the causal connection is inverse: People do not unsubscribe because Webware will not be expanded, but Webware cannot be expanded because developers and users lost interest (already some years ago). That in turn did not happen because Webware was a bad project, but because of many different reasons, some of them pointed out in my last posting, also because of the loss of you as driving force and because so many other exciting frameworks, standards, usage patterns and tools started to blossom in the Python web world. I'm completely open to following other plans for the future development of Webware, but if that means huge efforts, we will also need the people willing to do that work. Even following my outlined path will mean a lot of work for me if I need to do it alone. There must be also good reasons for putting efforts in proprietary development when we can just as well make use of existing tools and libraries. There are also new requirements and challenges such as support for AJAX, JSON, widgets, templating engines, ORMs, i18n etc. that must be better integrated into Webware to make it a really competitive framework for today. Currently Webware is a pretty monolithic framework like Django. That works quite well if many people are using it and you have many developers (as is the case for Django, but not for Webware). I want Webware to go more into the direction of TurboGears by focusing on its "core competencies" and making use of (the best-of-breed of) external tools and libraries for everything else. This works much better when there are not so many developers (as in the case of TurboGears and Webware ;-) I think this approach is also more clever and efficient. We may disagree a bit about what *are* the core competencies of Webware, so we should discuss that as well. E.g. is it more "Webware the app server" or "Webware the framework"? As a Webware developer I care more about the Webware framework API than the actual app server. > Regarding plug-ins, AFAIK setuptools, distutils, etc. don't cover > automatic discovery by an application server, augmenting app server > admin pages, versioning, etc. which is where I was planning on going > with Webware plug-ins. No one ever seemed to understand that and I > never found the time to develop them further with more capabilities, > code and docs. Oh, well. As far as I understand, this is exactly the idea behind "entry points" in setuptools. > Regarding unicode, isn't that baked into Python strings in 3.0? Does > anything have to "be done"? On .NET which is where I've been doing a > lot of work in lately, Unicode is simply implicit and free. Right, unicode is supported by Python 2 already (for some problems see http://www.cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python), but the point is that the Webware write() methods do not support automatic encoding of unicode. Currently, Webware apps work with encoded byte strings (latin-1 or utf-8) end-to-end. But that's different from the recommended (and in Python 3 enforced) way of always working with unicode strings and decoding/encoding only for input/output. I.e. the write() method should automatically encode (maybe even depending on accept-encoding headers), and fields from the database should be automatically decoded to unicode, etc. This alone will need some change and effort when porting Webware to Python 3. > I agree with the 1.1 idea of removing support for old versions of Python. By that I mean that I also want to make use of newer Python features so that the code will look less ugly and become more performant. > Regarding naming conventions, we discussed the following enhancement > on this list a long time ago, but no one got around to implementing > it. Here's a recap: > > Support you prefer to say obj.foo_bar() over WebKit's obj.fooBar()? We > can provide that by enhancing WebKit.Object's __getattr__ to look up > "fooBar" for any "foo_bar", enhance the __dict__ of the class where > "fooBar" was located to now have an entry for "foo_bar" and return the > value. This is only slow on the first fetch and just as fast as usual > afterwards. > > Another idea was to make things like self.request() into properties so > you can say self.request. You can avoid breaking existing code by > simply adding a WebKit.Object.__call__ that returns self. Pretty neat, > imo. These are things I already planned to implement in upcoming versions. This would also allow us to optionally print deprecation warnings when the old names are used and make migration much easier. The old names could then be phased out in version 3.0 or 4.0 or so. Another problem are the upper/camelcase names of the modules and packages which should be lowercase nowadays. Maybe we can provide a similar mechanism via the import hooks we are using anyway. > Personally, I enjoy using WebKit and MiddleKit and I also make use of > various tools in MiscUtils and WebUtils. The productivity there is > still good so I've had zero incentive to move existing apps to other > frameworks. I'm working on such a project this very week. Personally I'm using mainly WebKit, my apps use DBUtils with plain SQL or SQLAlchemy for accessing the database. That's why maintaining MiddleKit is difficult for me, though I tried to brush it up for the 1.0 version anyway. In the long run (2.0 or 3.0) I think it should be factored out into a separate project that can be maintained independently of Webware. I did the same with DBUtils, which can be installed as Webware plug-in and with distutils; it works very well. I'm not using any other of the standard plug-ins. I always thought FormKit might be useful and wanted to revamp and improve it, but never found the time and energy. Future Webware versions might support FormEncode and ToscaWidgets instead. > Had I put more consistent effort into Webware through the years, > including updating it with the times, then it might have become the > premiere app server for the Python community. Your departure certainly was the main reason why Webware stalled after the 0.8.1 release and never really regained momentum after that. It's always a big problem and a challenge if the original founder and owner of a project phases out. I saw the same happening with TurboGears which is also moving moving forward very bumpily after Kevin Dangoor left. That's not meant as an accusation; it just seems you or Kevin are persons who like tackling huge, venturous projects such as Webware (or even Cobra) more than the continuous maintenance and boring detail work once the main work is done. Open source actually needs both kinds of people. > In addition to moving towards Cobra 1.0, I'm also looking to make it > multibackend starting with JVM support and following that with a cross > VM library (VM = Virtual Machine as in .NET or JVM). It will then > become interesting to ask if there should be a cross VM app server... > a Webware for Cobra. So that may become the real replacement for Webware's appserver then :-) -- Christoph ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Webware-devel mailing list Webware-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-devel
