On Nov 21, 2007 4:27 AM, Graham Higgins
<gjh-...@public.gmane.org> wrote:

The problem is modularity. I may not be interested in TurboLog, Docudo, Plone, TRAC, pyBlosxom, etc in their entirety, but I'd like to use components from them if they were easily extractable, or even smaller functions to do certain tasks. That is the essence of Paste and Pylons, so it would be nice to extend this to a richer set of tools. For instance, we've talked about embedding wikis or a TRAC-like project manager into our sites eventually. Maybe we don't want all of Plone but that WYSIWYG text area that automatically recognizes formatted Word text would be useful. Things like that. Some users want a complete blog system ready to embed. Others want to take certain features and plug them into their own blog system, or even their not-really-a-blog system.

I'm curious about this. What do you mean?

We've got two or three types of users. One is the hacker type who prefers low-level tools like Paste, but found Pylons too convenient to ignore. These are people who might otherwise build their sites from scratch (SimpleHTTPServer, web.py).

At the other extreme is the stereotypical "Brian" who wants something high-level that works out of the box, with AJAX, authentication, form widgets, DB browser, admin interface, and all the other gee-whiz features. These are the people who might otherwise choose Rails, Django, PHP, Java, etc. These people have generally passed up on Pylons because the features and ease-of-use aren't quite there yet.

Then there's people in between who like Pylons' modularity for philosophical reasons, and/or also appreciate the add-ons (auth, internationalization, documentation, a future blog plugin, etc). Probably the majority of users fall into this category.

Deployer-friendly features are of interest to both the second two groups, so there will continue to be increasing calls for those, although not in the Pylons core. However, calls for these are not new; they've been rumbling for at least a year. The developers have always responded, "That's a great idea but we don't have time to do it right now." It's generally assumed that these will be available in a year or so.

The most exciting thing to happen is TG's new interoperability with Pylons because it brings some of these features ready-made. Even more interesting is the @expose decorator added to Pylons-dev, which brings some of TG's output-mode flexibility to Pylons. It's interesting in the sense of, "If they can do this, what next?"

Thus coming back to the question I raised earlier, how to embed a Pylons app in a Pylons app. One can embed at several different levels, so there are multiple answers to this. paste.urlmap, paste.cascade, route to a WSGI controller, have a stub controller that imports a Pylons app and uses make_app as a pseudo-controller. All of these seem viable but none have been well tested among the userbase.

AuthKit is trying to be that for Pylons, and for WSGI generally. But some sites also need to span non-WSGI and non-Python components. And ultimately you need a top-level authority for authentication/logging/sessions, something that all the compnents can "subscribe" to. It seems like the best answer now is to do this in middleware.py, because if you composite at the Paste config level or Apache you can't use a nice Pylons auth or logging feature.

I'm also really wondering about Repoze. Plone advocates are quite excited about it, as bringing a new generation of mix n match which will make the choice of framework irrelevant, or bring about the demise of standalone frameworks. I still don't quite understand it, or how much of the hype is really true vs Zope groupthink ("everybody wants Zope, they just don't realize it yet"). For us the question is more, will it help us embed Zope-using components? The other question is, will it sweep Pylons away? What, if anything, should we do for Pylons 1.0 to be more compatible with this? But it certainly sounds like a major breakthrough for Plone in any case. Plone has been stuck at Zope 2 due to the enormous work of upgrading. But it sounds like Plone will get Zope 3 and WSGI in one fell swoop, which would certainly make me more favorable toward Pone.

The only concrete advantage in Repoze that I've seen for non-Zope components is, "allow for systems that participate in a WSGI pipeline to make use of the existing two-phase commit transaction management provided by the ZODB transaction package." Um, that assumes one needs two-phase committing and versioning and an object database, doesn't it? Not quite revolutionary.

http://www.oreillynet.com/onlamp/blog/2007/11/grok_repoze_and_wsgi_beg_the_q_1.html