Paul Boddie
Posts: 26
Nickname: pboddie
Registered: Jan, 2006
|
|
Re: Python Enterprise Edition
|
Posted: Mar 6, 2006 7:45 AM
|
|
> Maybe my formulation was ambiguous. With "analogous to
> JEE" I meant the naming pattern not the JSR process
J2EE predated the JSR process by many years, and the JSR process was only created to give some impression/illusion (choose your interpretation) of openness and community involvement given Sun's lack of interest in a proper open source licence on their Java techologies.
> What I want is an officially endorsed
> python software distribution for the enterprise.
Here's how far that effort got in its last incarnation:
http://www.python-in-business.org/
A Zope "Site Error": yes a cheap shot, but as far as I can tell either no-one was really that interested or it was seen as irrelevant, anyway. There are Python distributions for different purposes, and that's possibly the most interesting avenue in this regard.
> Thus creating a defacto standard in python software for
> the enterprise and allowing the best of breed opensource
> python packages out there to gain momentum and maturity
> (which is currently my first and foremost concern).
Note that whilst you mentioned J2EE, nominating megaframeworks is not really what J2EE does. You can possibly argue that there's a blatant proliferation of Java frameworks for, amongst other things, Web application development, but in fact the market (particularly the job market) seems to have settled on a few, now unfashionable (if you wallow too much in RoR hype) solutions.
As I've said all along, just as the unfashionable J2EE sets standards for interoperability, and just as things like the DB-API do the same at a useful level for Python, so should the Python community reduce wheel reinvention by agreeing on useful standards. The Web-SIG has taken two years to agree on WSGI, but that doesn't even get it to the point of meeting its own initial goals.
> That would make it also easier for beginners that are
> searching a way too start with python enterprise
> development, they can then start with the standard and
> won't be too wrong.
Yes, useful standards are essential - not just "on which servers can I deploy?" but also "what will the code look like?" and "will I have to rewrite this code or learn another API if I change some components?".
> Of course if one megaframework will not be part of the
> standard that doesn't mean the development will have to
> stop there. There can always be a cross-pollination
> between standard frameworks and and non-standard
> frameworks.
Only if there are standards to facilitate that. It's arguably not yet the case that such standards exist. Meanwhile, picking a megaframework will just lead to another Zope situation: a separate community and a different track at conferences - something the Zope community actually realise now.
|
|
Previous Topic
