> What I was trying to say with my Zope 2 example is that there is > actually some level of knowledge sharing and it's not just for the > very smart, or the very involved. Quite a few people know their ropes > around a Zope 2 application (or perhaps I mean mostly CMF). > > Yes, but there's not a management tool associated with any of these > (in the Zope 2 sense of "/manage"); you can't manage or get numbers > out of any of these without looking through log files or writing code > (or writing a configuration file). > > I think it depends whether it's a single-developer scenario or a > team-based, long-running project, whether you can benefit from any of > this "management" stuff. >
I've had similar thoughts these days. These are definitely two application server features missing in pyramid (well, not really missing) - the integrated server management (Control Panel in Zope) with restart option and connection details, web based log viewer - and the persistent machinery with multithreading and multiserver awareness (I don't refer to this as a data storage) to handle apllication configuration through a browser interface without restarting every single instance I think especially for "high-level" applications such functions are necessary to get a wider acceptance. However, I think the required components all exist loosely they just have to be tied together in a package and API. Background is, I'm currently implementing a "high-level" content management system on top of pyramid (running on top of zope 2 before) and except these two points pyramid fits and works perfectly well. (I plan a first release in january and hopefully it will draw some attention.) Arndt. -- 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.
