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

Reply via email to