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
|