Thanks Mike. More detailed post. I have gone through the Graham's discussion list and some of the web pages. I stayed away from Zope & Plone stuffs since people scare me on learning curve.
As you mentioned, Pylons 2.0/x.y may hide the implementation details of marco and yet provide rather more pluggable framework. I have used the IoC extensively in .NET applications and curious to know how it is works in the making python web components. Once things formally announced, I can look at the source code to learn the progress. May be separate user group shall be good for discussion. Does this new architecture support running multiple applications together to make one website? For example, say we have a blog application, forum application, poll, feedback and cms application but we can assemble them together to make the website. I think, Rails 3 (/ Merb), tries the similar stuff. I wish you the best for development of Marco. Regards, Krish On Dec 31, 12:40 am, Mike Orr <[email protected]> wrote: > On Wed, Dec 30, 2009 at 1:26 AM, [email protected] > > <[email protected]> wrote: > > So does this mean that Marco is entirely different framework and no > > relation with Pylons? I had impression that Pylons 2.0 shall be called > > as meta framework. > > The Marco core is a meta-framework, akin to Paste. It will have > several framework personalities on top of it, including a Pylons-ish > one, a TG2-ish one, and a repoze.BFG-ish one. How it will be branded > will be decided later. So the "Marco" package in PyPI may end up > refering to all of the above, or just to the common core. But either > way it will be possible to install the full kit with several framework > personalities, or just the parts you're interested in. > > The Pylons-ish framework can currently run some Pylons applications, > so I've heard. If it succeeds it will likely become "Pylons 2". > > Pylons is like an onion, so it can be difficult to answer, "What is > Pylons, and how many changes can you make before it's not Pylons > anymore?" In one sense, Pylons is the package called 'pylons'. But a > Pylons application includes more, and is held together via Paste. But > from a user's perspective, what matters is whether you can run > existing Pylons applications unchanged, and whether there are syntax > changes. > > The goal of a Pylons-ish personality is to run Pylons 1 applications > (and hopefully 0.9.7 applications) with no changes to the controller > code, routing, templates, special globals, 'config' object, or INI > file. There may be a front-end configuration step: you may launch it > via something other than "paster serve development.ini", or the INI > file may be replaced by something equivalent. > > I envision one personality for existing Pylons applications, and > another that would be free to make some syntax changes, such as > perhaps replacing the special globals with controller-instance > attributes. The latter might be called "Pylons 2", while the former > would just be "the Marco port of Pylons". It just depends on what > marketing/branding we want to do when the time comes. The code will > be the same no matter what the branding is, and maintained by > Pylons/TG developers as it is now. > > > Do we have any document or discussion to understand where the Pylons > > lacks and how Marco solves the problem? > > I tried to explain it in the Roadmap > (http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0). > Graham's webpages record the raw discussion. The main point is, it's > more of interest to framework developers than framework users. > > Marco is an extension of what Pylons is already doing. Pylons is "the > modular framework built on Paste/WSGI". Marco makes it even more > modular. Currently you can plug in any server and an application in > the INI file, any middleware in middleware.py, and any template engine > by reimplementing render_mako(). Marco allows framework developers to > plug in reusable framework components in a similar way. You can > "build your own framework" by plugging in the dispatch/routing style, > request/response style, etc, that you prefer. > > The name for this is componentization. Zope.component provides the > underlying architecture. A configuration file specifies which > components to plug in to make a framework. Pylons users wouldn't > worry about this: it's all handled in the Pylons-ish personality. > > But a future user could, if he wanted to, specify the equivalent of a > Pylons application (with components, routing, and configuration), all > in a single configuration file. It may be in XML, YAML, Python, or > another format -- Marco accepts multiple configuration formats. > > Basically, in 2005 we tried to make framework code more interoperable > with WSGI and Paste. That worked well but has some limitations. WSGI > was originally envisioned to connect an aribitrary application to an > arbitrary server. It happened to allow middleware, and this gave > increased pluggability. But five years' experience has shown that raw > WSGI is too clunky for many things, even if it still does its original > job well. WebOb provides an abstraction above WSGI. And now Marco > provides a way to componentize all parts of the framework beyond what > middleware/Paste INI can do. We found a component architecture > already existing in Zope, extracted from the rest of Zope in Repoze, > and decided it was better than building our own. (Because it works > and has been tested for ten years.) So that is what has led to this > point. > > The public discussion in Graham's archive goes from January to July > 2009. After that, ChrisM and Ben were collaborating privately on > their own prototypes, and the discussions weren't archived. I haven't > been involved directly since April due to other commitments. But we > (the Pylons/TG/BFG developers) are all interested in seeing what comes > out of the prototypes, and hope to get more involved in it as we > finish our other commitments (Pylons 1.0, documentation, etc). > > -- > Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
