From chrism at plope.com Mon Jul 6 03:47:42 2009 From: chrism at plope.com (Chris McDonough) Date: Sun, 05 Jul 2009 21:47:42 -0400 Subject: [Web-SIG] repoze.bfg web framework 1.0 released Message-ID: <4A5157BE.60201@plope.com> Summary ------- The first major release of the BFG web framework (aka "repoze.bfg"), version 1.0, is available. See http://bfg.repoze.org/ for general information about repoze.bfg. Details ------- BFG is a Python web framework based on WSGI. It is inspired by Zope, Pylons, and Django. It makes use of a number of Zope technologies under the hood. BFG is developed as part of the more general Repoze project (http://repoze.org). It is released under the BSD-like license available from http://repoze.org/license.html . BFG version 1.0 represents one year of development effort. The first release of BFG, version 0.1, was made in July of 2008. Since then, roughly 80 pre-1.0 releases have been made. None of these pre-1.0 releases explicitly promised any backwards compatibility with any earlier release. Version 1.0, however, marks the first point at which the repoze.bfg API has been "frozen". Future releases in the 1.X line guarantee API-level backward compatibility with 1.0. A backwards incompatibility with 1.0 at the API level in any future 1.X version will be considered a bug. More Details ------------ BFG contains moderate, incremental improvements to patterns found in earlier-generation web frameworks. It tries to make real-world web application development and deployment more fun, more predictable, and more productive. To this end, BFG has the the following features: - WSGI-based deployment: PasteDeploy and mod_wsgi compatible. - Runs under Python 2.4, 2.5, and 2.6. - Runs on UNIX, Windows, and Google App Engine. - Full documentation coverage: no feature or API is undocumented. - A comprehensive set of unit tests. The repoze.bfg package contains 11K lines of Python code. 8000 lines of that total line count is unit test code that tests the remaining 3000 lines. - Sparse resource utilization: BFG has a small memory footprint and doesn't waste any CPU cycles. - Doesn't have an unreasonable set of dependencies: "easy_install" -ing repoze.bfg over broadband takes less than a minute. - Quick startup: a typical BFG application starts up in about a second. - Offers extremely fast XML/HTML and text templating via Chameleon (http://chameleon.repoze.org/). - Persistence-agnostic: use SQLAlchemy, "raw" SQL, ZODB, CouchDB, filesystem files, LDAP, or anything else which suits a particular application's needs. - Provides a variety of starter project templates. Each template makes it possible to quickly start developing a BFG application using a particular application stack. - Offers URL-to-code mapping like Django or Pylons' *URL routing* or like Zope's *graph traversal*, or allows a combination of both routing and traversal. This helps make it feel familiar to both Zope and Pylons developers. - Offers debugging modes for common development error conditions (for example, when a view cannot be found, or when authorization is being inappropriately granted or denied). - Allows developers to organize their code however they see fit; the framework is not opinionated about code structure. - Allows developers to write code that is easily unit-testable. Avoids using thread local data structures which hamper testability. Provides helper APIs which make it easy to mock framework components such as templates and views. - Provides an optional declarative context-sensitive authorization system. This system prevents or allows the execution of code based on a comparison of credentials possessed by the requestor against ACL information stored by a BFG application. - Behavior of an an application built using BFG can be extended or overridden arbitrarily by a third-party developer without any modification to the original application's source code. This makes BFG a good choice for building frameworks and other "extensible applications". - Zope and Plone developers will be comfortable with the terminology and concepts used by BFG; they are almost all Zope-derived. Excruciating Details -------------------- Quick installation: easy_install -i http://dist.repoze.org/bfg/current repoze.bfg General support and information: http://bfg.repoze.org Tutorials http://docs.repoze.org/bfg/current/#tutorials Sample Applications http://docs.repoze.org/bfg/current/#sample-applications Detailed narrative and API documentation: http://docs.repoze.org/bfg/current Bug tracker: http://bfg.repoze.org/trac Maillist: http://lists.repoze.org/listinfo/repoze-dev IRC support: irc://irc.freenode.net#repoze repoze.bfg is developed primarily by Agendaless Consulting (http://agendaless.com) and a team of contributors. Special thanks to these people, without whom this release would not have been possible: Malthe Borch, Carlos de la Guardia, Chris Rossi, Shane Hathaway, Tom Moroz, Yalan Teng, Jason Lantz, Todd Koym, Jessica Geist, Hanno Schlichting, Reed O'Brien, Sebastien Douche, Ian Bicking, Jim Fulton, Martijn Faassen, Ben Bangert, Fernando Correa Neto, YoungKing, Rob Miller, Wichert Akkermann, David Pratt, Mark Ramm, and Chris Perkins. From graham.dumpleton at gmail.com Mon Jul 6 04:37:48 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Mon, 6 Jul 2009 12:37:48 +1000 Subject: [Web-SIG] repoze.bfg web framework 1.0 released In-Reply-To: <4A5157BE.60201@plope.com> References: <4A5157BE.60201@plope.com> Message-ID: <88e286470907051937qb178ebdo334b3561995f3a3@mail.gmail.com> > The first major release of the BFG web framework (aka "repoze.bfg"), > version 1.0, is available. ?See http://bfg.repoze.org/ for general > information about repoze.bfg. > > ... > > - WSGI-based deployment: PasteDeploy and mod_wsgi compatible. > > ... > > - A comprehensive set of unit tests. ?The repoze.bfg package contains > ?11K lines of Python code. ?8000 lines of that total line count is > ?unit test code that tests the remaining 3000 lines. A question about your testing if you have time. Is this done in a fake WSGI hosting environment, ie., test harness, or is it able to be run through WSGI servers such as Paste server, Apache/mod_wsgi, etc, in some way? Am curious from the point of view that standalone test suites for WSGI itself to run against WSGI hosting mechanisms don't really exist, so the test suite for BFG, with the presumption that it would exercise a lot of WSGI functionality, might be a good regression test for WSGI servers themselves. Graham From randy at rcs-comp.com Mon Jul 6 05:44:55 2009 From: randy at rcs-comp.com (Randy Syring) Date: Sun, 5 Jul 2009 22:44:55 -0500 Subject: [Web-SIG] repoze.bfg web framework 1.0 released In-Reply-To: <4A5157BE.60201@plope.com> References: <4A5157BE.60201@plope.com> Message-ID: <2d07a6f90907052044y75ad1b4ancc303a58cd7319de@mail.gmail.com> Chris, Sounds interesting. Question: Does it support some kind of module/plugin architecture that will allow me to develop "plug- in" functionality across projects? What would be called in Django an "app". For example, I would like to have a "news", "blog", and "calendar" module that I can plug into different applications. The goal is to have everything for the module contained in one subdirectory or package including any configuration, routing, templates, controllers, model, etc. So, something like this: /modules/news/... /modules/calendar/... /modules/blog/... Or: packages/ MyProj NewsComponent CalendarComponent BlogComponent I ended up writing my own framework because I needed this and didn't want to go with Django and Pylons didn't support it: http://groups.google.com/group/pylons-discuss/browse_thread/thread/14aef22ddb90347f But would love to be able to use something else that was more of a community effort. Thanks. -- -------------------------------------- Randy Syring RCS Computers & Web Solutions 502-644-4776 http://www.rcs-comp.com "Whether, then, you eat or drink or whatever you do, do all to the glory of God." 1 Cor 10:31 On Sun, Jul 5, 2009 at 8:47 PM, Chris McDonough wrote: > Summary > ------- > > The first major release of the BFG web framework (aka "repoze.bfg"), > version 1.0, is available. See http://bfg.repoze.org/ for general > information about repoze.bfg. > > Details > ------- > > BFG is a Python web framework based on WSGI. It is inspired by Zope, > Pylons, and Django. It makes use of a number of Zope technologies > under the hood. > > BFG is developed as part of the more general Repoze project > (http://repoze.org). It is released under the BSD-like license > available from http://repoze.org/license.html . > > BFG version 1.0 represents one year of development effort. The first > release of BFG, version 0.1, was made in July of 2008. Since then, > roughly 80 pre-1.0 releases have been made. None of these pre-1.0 > releases explicitly promised any backwards compatibility with any > earlier release. > > Version 1.0, however, marks the first point at which the repoze.bfg > API has been "frozen". Future releases in the 1.X line guarantee > API-level backward compatibility with 1.0. A backwards > incompatibility with 1.0 at the API level in any future 1.X version > will be considered a bug. > > More Details > ------------ > > BFG contains moderate, incremental improvements to patterns found in > earlier-generation web frameworks. It tries to make real-world web > application development and deployment more fun, more predictable, and > more productive. To this end, BFG has the the following features: > > - WSGI-based deployment: PasteDeploy and mod_wsgi compatible. > > - Runs under Python 2.4, 2.5, and 2.6. > > - Runs on UNIX, Windows, and Google App Engine. > > - Full documentation coverage: no feature or API is undocumented. > > - A comprehensive set of unit tests. The repoze.bfg package contains > 11K lines of Python code. 8000 lines of that total line count is > unit test code that tests the remaining 3000 lines. > > - Sparse resource utilization: BFG has a small memory footprint and > doesn't waste any CPU cycles. > > - Doesn't have an unreasonable set of dependencies: "easy_install" > -ing repoze.bfg over broadband takes less than a minute. > > - Quick startup: a typical BFG application starts up in about a > second. > > - Offers extremely fast XML/HTML and text templating via Chameleon > (http://chameleon.repoze.org/). > > - Persistence-agnostic: use SQLAlchemy, "raw" SQL, ZODB, CouchDB, > filesystem files, LDAP, or anything else which suits a particular > application's needs. > > - Provides a variety of starter project templates. Each template > makes it possible to quickly start developing a BFG application > using a particular application stack. > > - Offers URL-to-code mapping like Django or Pylons' *URL routing* or > like Zope's *graph traversal*, or allows a combination of both > routing and traversal. This helps make it feel familiar to both > Zope and Pylons developers. > > - Offers debugging modes for common development error conditions (for > example, when a view cannot be found, or when authorization is being > inappropriately granted or denied). > > - Allows developers to organize their code however they see fit; the > framework is not opinionated about code structure. > > - Allows developers to write code that is easily unit-testable. > Avoids using thread local data structures which hamper testability. > Provides helper APIs which make it easy to mock framework components > such as templates and views. > > - Provides an optional declarative context-sensitive authorization > system. This system prevents or allows the execution of code based > on a comparison of credentials possessed by the requestor against > ACL information stored by a BFG application. > > - Behavior of an an application built using BFG can be extended or > overridden arbitrarily by a third-party developer without any > modification to the original application's source code. This makes > BFG a good choice for building frameworks and other "extensible > applications". > > - Zope and Plone developers will be comfortable with the terminology > and concepts used by BFG; they are almost all Zope-derived. > > Excruciating Details > -------------------- > > Quick installation: > > easy_install -i http://dist.repoze.org/bfg/current repoze.bfg > > General support and information: > > http://bfg.repoze.org > > Tutorials > > http://docs.repoze.org/bfg/current/#tutorials > > Sample Applications > > http://docs.repoze.org/bfg/current/#sample-applications > > Detailed narrative and API documentation: > > http://docs.repoze.org/bfg/current > > Bug tracker: > > http://bfg.repoze.org/trac > > Maillist: > > http://lists.repoze.org/listinfo/repoze-dev > > IRC support: > > irc://irc.freenode.net#repoze > > repoze.bfg is developed primarily by Agendaless Consulting > (http://agendaless.com) and a team of contributors. > > Special thanks to these people, without whom this release would not > have been possible: > > Malthe Borch, Carlos de la Guardia, Chris Rossi, Shane Hathaway, Tom > Moroz, Yalan Teng, Jason Lantz, Todd Koym, Jessica Geist, Hanno > Schlichting, Reed O'Brien, Sebastien Douche, Ian Bicking, Jim Fulton, > Martijn Faassen, Ben Bangert, Fernando Correa Neto, YoungKing, Rob > Miller, Wichert Akkermann, David Pratt, Mark Ramm, and Chris Perkins. > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/randy%40rcs-comp.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Mon Jul 6 05:50:28 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Mon, 6 Jul 2009 13:50:28 +1000 Subject: [Web-SIG] repoze.bfg web framework 1.0 released In-Reply-To: <2d07a6f90907052044y75ad1b4ancc303a58cd7319de@mail.gmail.com> References: <4A5157BE.60201@plope.com> <2d07a6f90907052044y75ad1b4ancc303a58cd7319de@mail.gmail.com> Message-ID: <88e286470907052050r2e34de85k555d589fcd451d74@mail.gmail.com> 2009/7/6 Randy Syring : > Chris, > > Sounds interesting.? Question: Does it support some > kind of module/plugin architecture that will allow me to develop "plug- > in" functionality across projects? ?What would be called in > Django an "app". The documentation says: """ Like Zope, but unlike Pylons applications or most Django applications, when you build a repoze.bfg application, if you obey certain constraints, the application you produce can be reused, modified, re-integrated, or extended by third-party developers without modification to the original application itself. See Extending An Existing repoze.bfg Application for more information about extending or modifying an existing repoze.bfg application. """ http://docs.repoze.org/bfg/current/narr/introduction.html#differences-from-other-frameworks http://docs.repoze.org/bfg/current/narr/extending.html#extending-chapter Graham > For example, I would like to have a "news", "blog", and "calendar" > module that I can plug into different applications. ?The goal is to > have everything for the module contained in one subdirectory or package > including > any configuration, routing, templates, controllers, model, etc. ?So, > something like this: > > /modules/news/... > /modules/calendar/... > /modules/blog/... > > Or: > > packages/ > ?? MyProj > ?? NewsComponent > ?? CalendarComponent > ?? BlogComponent > > I ended up writing my own framework because I needed this and didn't want to > go with Django and Pylons didn't support it: > > http://groups.google.com/group/pylons-discuss/browse_thread/thread/14aef22ddb90347f > > But would love to be able to use something else that was more of a community > effort. > > Thanks. > -- > -------------------------------------- > Randy Syring > RCS Computers & Web Solutions > 502-644-4776 > http://www.rcs-comp.com > > "Whether, then, you eat or drink or whatever you do, do all to the glory of > God." 1 Cor 10:31 > > > On Sun, Jul 5, 2009 at 8:47 PM, Chris McDonough wrote: >> >> Summary >> ------- >> >> The first major release of the BFG web framework (aka "repoze.bfg"), >> version 1.0, is available. ?See http://bfg.repoze.org/ for general >> information about repoze.bfg. >> >> Details >> ------- >> >> BFG is a Python web framework based on WSGI. ?It is inspired by Zope, >> Pylons, and Django. ?It makes use of a number of Zope technologies >> under the hood. >> >> BFG is developed as part of the more general Repoze project >> (http://repoze.org). ?It is released under the BSD-like license >> available from http://repoze.org/license.html . >> >> BFG version 1.0 represents one year of development effort. ?The first >> release of BFG, version 0.1, was made in July of 2008. ?Since then, >> roughly 80 pre-1.0 releases have been made. ?None of these pre-1.0 >> releases explicitly promised any backwards compatibility with any >> earlier release. >> >> Version 1.0, however, marks the first point at which the repoze.bfg >> API has been "frozen". ?Future releases in the 1.X line guarantee >> API-level backward compatibility with 1.0. ?A backwards >> incompatibility with 1.0 at the API level in any future 1.X version >> will be considered a bug. >> >> More Details >> ------------ >> >> BFG contains moderate, incremental improvements to patterns found in >> earlier-generation web frameworks. ?It tries to make real-world web >> application development and deployment more fun, more predictable, and >> more productive. ?To this end, BFG has the the following features: >> >> - WSGI-based deployment: PasteDeploy and mod_wsgi compatible. >> >> - Runs under Python 2.4, 2.5, and 2.6. >> >> - Runs on UNIX, Windows, and Google App Engine. >> >> - Full documentation coverage: no feature or API is undocumented. >> >> - A comprehensive set of unit tests. ?The repoze.bfg package contains >> ?11K lines of Python code. ?8000 lines of that total line count is >> ?unit test code that tests the remaining 3000 lines. >> >> - Sparse resource utilization: BFG has a small memory footprint and >> ?doesn't waste any CPU cycles. >> >> - Doesn't have an unreasonable set of dependencies: "easy_install" >> ?-ing repoze.bfg over broadband takes less than a minute. >> >> - Quick startup: a typical BFG application starts up in about a >> ?second. >> >> - Offers extremely fast XML/HTML and text templating via Chameleon >> ?(http://chameleon.repoze.org/). >> >> - Persistence-agnostic: use SQLAlchemy, "raw" SQL, ZODB, CouchDB, >> ?filesystem files, LDAP, or anything else which suits a particular >> ?application's needs. >> >> - Provides a variety of starter project templates. ?Each template >> ?makes it possible to quickly start developing a BFG application >> ?using a particular application stack. >> >> - Offers URL-to-code mapping like Django or Pylons' *URL routing* or >> ?like Zope's *graph traversal*, or allows a combination of both >> ?routing and traversal. ?This helps make it feel familiar to both >> ?Zope and Pylons developers. >> >> - Offers debugging modes for common development error conditions (for >> ?example, when a view cannot be found, or when authorization is being >> ?inappropriately granted or denied). >> >> - Allows developers to organize their code however they see fit; the >> ?framework is not opinionated about code structure. >> >> - Allows developers to write code that is easily unit-testable. >> ?Avoids using thread local data structures which hamper testability. >> ?Provides helper APIs which make it easy to mock framework components >> ?such as templates and views. >> >> - Provides an optional declarative context-sensitive authorization >> ?system. ?This system prevents or allows the execution of code based >> ?on a comparison of credentials possessed by the requestor against >> ?ACL information stored by a BFG application. >> >> - Behavior of an an application built using BFG can be extended or >> ?overridden arbitrarily by a third-party developer without any >> ?modification to the original application's source code. ?This makes >> ?BFG a good choice for building frameworks and other "extensible >> ?applications". >> >> - Zope and Plone developers will be comfortable with the terminology >> ?and concepts used by BFG; they are almost all Zope-derived. >> >> Excruciating Details >> -------------------- >> >> Quick installation: >> >> ?easy_install -i http://dist.repoze.org/bfg/current repoze.bfg >> >> General support and information: >> >> ?http://bfg.repoze.org >> >> Tutorials >> >> ?http://docs.repoze.org/bfg/current/#tutorials >> >> Sample Applications >> >> ?http://docs.repoze.org/bfg/current/#sample-applications >> >> Detailed narrative and API documentation: >> >> ?http://docs.repoze.org/bfg/current >> >> Bug tracker: >> >> ?http://bfg.repoze.org/trac >> >> Maillist: >> >> ?http://lists.repoze.org/listinfo/repoze-dev >> >> IRC support: >> >> ?irc://irc.freenode.net#repoze >> >> repoze.bfg is developed primarily by Agendaless Consulting >> (http://agendaless.com) and a team of contributors. >> >> Special thanks to these people, without whom this release would not >> have been possible: >> >> Malthe Borch, Carlos de la Guardia, Chris Rossi, Shane Hathaway, Tom >> Moroz, Yalan Teng, Jason Lantz, Todd Koym, Jessica Geist, Hanno >> Schlichting, Reed O'Brien, Sebastien Douche, Ian Bicking, Jim Fulton, >> Martijn Faassen, Ben Bangert, Fernando Correa Neto, YoungKing, Rob >> Miller, Wichert Akkermann, David Pratt, Mark Ramm, and Chris Perkins. >> _______________________________________________ >> Web-SIG mailing list >> Web-SIG at python.org >> Web SIG: http://www.python.org/sigs/web-sig >> Unsubscribe: >> http://mail.python.org/mailman/options/web-sig/randy%40rcs-comp.com > > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > > From randy at rcs-comp.com Mon Jul 6 06:01:50 2009 From: randy at rcs-comp.com (Randy Syring) Date: Mon, 06 Jul 2009 00:01:50 -0400 Subject: [Web-SIG] repoze.bfg web framework 1.0 released In-Reply-To: <88e286470907052050r2e34de85k555d589fcd451d74@mail.gmail.com> References: <4A5157BE.60201@plope.com> <2d07a6f90907052044y75ad1b4ancc303a58cd7319de@mail.gmail.com> <88e286470907052050r2e34de85k555d589fcd451d74@mail.gmail.com> Message-ID: <4A51772E.1070203@rcs-comp.com> Graham Dumpleton wrote: > 2009/7/6 Randy Syring : > >> Chris, >> >> Sounds interesting. Question: Does it support some >> kind of module/plugin architecture that will allow me to develop "plug- >> in" functionality across projects? What would be called in >> Django an "app". >> > > The documentation says: > > """ > Like Zope, but unlike Pylons applications or most Django applications, > when you build a repoze.bfg application, if you obey certain > constraints, the application you produce can be reused, modified, > re-integrated, or extended by third-party developers without > modification to the original application itself. See Extending An > Existing repoze.bfg Application for more information about extending > or modifying an existing repoze.bfg application. > """ > > http://docs.repoze.org/bfg/current/narr/introduction.html#differences-from-other-frameworks > http://docs.repoze.org/bfg/current/narr/extending.html#extending-chapter > > Graham > > Graham, Thanks for responding. I read that section above, but I don't think it answers my question. Or, maybe it does, just not the way I had hoped it would be answered. My understanding is that you can reuse/modify/extend/etc. applications. However, what I have in mind is not so much the integration of multiple applications as it is the integration of components into an application. The difference being that my "blog component" doesn't have any kind of DB settings or global templates. The configuration is minimal and only deals with things specific to the blog component (i.e. to allow coments or not). However, the application level configuration contains DB settings, admin emails, etc. and also has global templates (i.e. the main templates that define the look and feel for the entire site). So based on the documentation, I am certain I could extend an application if needed. However, the real question I have is: can an application be made up of "pluggable" components that can be reused between applications? -------------------------------------- Randy Syring RCS Computers & Web Solutions 502-644-4776 http://www.rcs-comp.com "Whether, then, you eat or drink or whatever you do, do all to the glory of God." 1 Cor 10:31 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrism at plope.com Mon Jul 6 17:32:35 2009 From: chrism at plope.com (Chris McDonough) Date: Mon, 06 Jul 2009 11:32:35 -0400 Subject: [Web-SIG] repoze.bfg web framework 1.0 released In-Reply-To: <88e286470907051937qb178ebdo334b3561995f3a3@mail.gmail.com> References: <4A5157BE.60201@plope.com> <88e286470907051937qb178ebdo334b3561995f3a3@mail.gmail.com> Message-ID: <4A521913.3040403@plope.com> On 7/5/09 10:37 PM, Graham Dumpleton wrote: >> The first major release of the BFG web framework (aka "repoze.bfg"), >> version 1.0, is available. See http://bfg.repoze.org/ for general >> information about repoze.bfg. >> >> ... >> >> - WSGI-based deployment: PasteDeploy and mod_wsgi compatible. >> >> ... >> >> - A comprehensive set of unit tests. The repoze.bfg package contains >> 11K lines of Python code. 8000 lines of that total line count is >> unit test code that tests the remaining 3000 lines. > > A question about your testing if you have time. Is this done in a fake > WSGI hosting environment, ie., test harness, or is it able to be run > through WSGI servers such as Paste server, Apache/mod_wsgi, etc, in > some way? The tests I mentioned in there are mostly unit tests; they don't test any particular system configuration functionally. In particular, none of the tests actually invokes a request via a WSGI stack. But we do use functional testing in projects that use the framework. For example, we use Twill (created by Titus Brown) to make sure things don't break at the request/response level in this project: http://karlproject.org. > Am curious from the point of view that standalone test suites for WSGI > itself to run against WSGI hosting mechanisms don't really exist, so > the test suite for BFG, with the presumption that it would exercise a > lot of WSGI functionality, might be a good regression test for WSGI > servers themselves. I think maybe some "ACID test" WSGI application could be built, and then some set of functional HTTP-level tests could be run against that application to gain confidence in a WSGI app. This is more or less what we do with Twill on that KARL project: the developers use the Paste#http server, but we actually deploy to a mod_wsgi server. We can (and do) run the Twill tests against both to get confidence that the app isn't going to fall over in production. - C From chrism at plope.com Mon Jul 6 18:33:23 2009 From: chrism at plope.com (Chris McDonough) Date: Mon, 06 Jul 2009 12:33:23 -0400 Subject: [Web-SIG] repoze.bfg web framework 1.0 released In-Reply-To: <2d07a6f90907052044x5fcf15e1udc38eb9c7640202d@mail.gmail.com> References: <4A5157BE.60201@plope.com> <2d07a6f90907052044x5fcf15e1udc38eb9c7640202d@mail.gmail.com> Message-ID: <4A522753.2070104@plope.com> On 7/5/09 11:44 PM, Randy Syring wrote: > Chris, > > Sounds interesting. Question: Does it support some > kind of module/plugin architecture that will allow me to develop "plug- > in" functionality across projects? What would be called in > Django an "app". > > For example, I would like to have a "news", "blog", and "calendar" > module that I can plug into different applications. The goal is to > have everything for the module contained in one subdirectory or package > including > any configuration, routing, templates, controllers, model, etc. So, > something like this: > > /modules/news/... > /modules/calendar/... > /modules/blog/... > > Or: > > packages/ > MyProj > NewsComponent > CalendarComponent > BlogComponent > I'm not sure if I can do this topic justice here (many have fallen on the sword when approaching it before), but I'll try. "Plugin apps" is maybe less a feature of BFG than the stuff that BFG is built on top of. Like Zope, BFG makes use of the Zope Component Architecture "under the hood". Unlike Zope, BFG tends to hide the ZCA (conceptually and API-wise) from developers, because the ZCA introduces concepts like "adapters", "interfaces", and "utilities". Direct exposure to these concepts in user-visible code evokes suspicion in people who just don't have the problems they try to solve. The problems that the ZCA tries to solve usually revolve around code testability and reusability, and most people just don't care that much about these things. So BFG is more like Pylons or Django in this respect: it provides helper APIs and places to hang your code so that you can build a single-purpose application reasonably easily without making you think in terms of building anything reusable. The final application usually happens to be overrideable and extensible, but that's just a byproduct of using BFG, and doesn't really have very much to do with building a system out of plugins. In the meantime, the Zope Component Architecture is a fantastic system on which to build a *framework* (as opposed to an application). This is why BFG is built on top of it. If you are willing to use the ZCA conceptually and API-wise *in your application code*, it becomes straightforward to build reusable applications like you mention. So the answer to your original question is probably no. BFG itself isn't a system which allows you to slot arbitrary components into place and have them "show up" somewhere. It's instead a system (like Zope) in which you can build such a thing. In fact, many of the applications that we (my company, Agendaless) build are these kinds of applications, where we tend to want to reuse a single application component across many "customers" or "projects". The trick is this: when you build "pluggable applications", there's presumably something you're going to want to plug these applications into. I *think* this the piece that most people are after when they talk about "pluggable applications"; they actually don't care too much about the applications themselves (because they'll build them themselves), it's the higher-level thing that gets plugged into that is of primary interest. For better or worse, systems like Plone, Drupal, and Joomla are examples of such an application framework. These systems allow you to build small pieces of functionality that drop in to some larger system. We've done lots of Zope and Plone work, and we know the downsides of the "plug this bit into the larger framework" pattern pretty well. We've found that it's useful to have the tools at hand to build miniature versions of such large frameworks on hand, so we can quickly come up with a custom solution to some problem without "fighting the framework" (any particular framework) so much. BFG plus direct use of the ZCA in application code tends to let us avoid using the larger frameworks in favor of rolling our own (more focused, simpler) frameworks. Unfortunately, I don't have any "simple example" application code to show with respect to this pattern, because anything I could show here would be too trivial to be useful. More unfortunately, anything I can point you to that we've built using this pattern will probably be too large to understand in any reasonable amount of time (e.g. http://karlproject.org). This has always been the historical problem with trying to promote use of the ZCA for application code: until you work on a larger project that uses it "right", it's just too abstract. So by the time you actually need it, it's too late and you've already invented your own mechanisms to do similar indirections. For those reasons, I think it would be a useful exercise to build some very simple system that took "app plugins" and just exposed them in some very concrete way to end users, even if it meant losing some presentation flexibility. Such a system could be created in any web framework, but using the ZCA inside the web framework for such a task is a no-brainer to me. Anyway, even this explanation is too abstract, so I'll stop it now. ;-) - C From jim at zope.com Sat Jul 11 13:05:22 2009 From: jim at zope.com (Jim Fulton) Date: Sat, 11 Jul 2009 07:05:22 -0400 Subject: [Web-SIG] Python hosting (was Re: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open questions on python-dev)) In-Reply-To: <02f30a119597a6bbacf2926429f14f67@preisshare.net> References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp> <20090709172515.1801C3A407B@sparrow.telecommunity.com> <4A56CFED.1030505@ar.media.kyoto-u.ac.jp> <3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com> <79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com> <5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com> <02f30a119597a6bbacf2926429f14f67@preisshare.net> Message-ID: On Jul 11, 2009, at 5:58 AM, David Lyon wrote: > On Fri, 10 Jul 2009 10:02:39 -0400, Jim Fulton wrote: >> I was really just pointing out that there isn't >> anything special about web developers. Really the need relates to >> application development. That is, web application developer's needs >> aren't really different from other application developers' needs. > > Just for my own education.. > > Why is there so many problems with python hosting? What I mean > is that any linux host that can run python should be able to > do web hosting easily. Say like run zope/plone. > > Is this due to difficulties in getting packages onto a web host? > > What could be done in an ideal world to make it a snap to > run zope on my cheapy linux web hosting service (that already > has python)? The primary problem is that most web applications require long-running processes and low-cost hosting providers don't let you run your own long-running processes. My impression is that not many low-cost providers support mod_python or that perhaps perhaps it's not easy to integrate with mod_python in those environments. I personally haven't tried to run Zope on low-cost hosting providers. Lots of people are gravitating to Google App Engine, including Zope developers. Zope itself is a bit too heavy for GAE, but lots of Zope developers are building lighter applications using Zope (and non-Zope) components. Lots of other frameworks work with GAE. Of course, there are lots of relatively low cost (~$20/mo) co-lo providers that give you a VM you can run anything on. I don't think there're any problems running Zope in those environments. Maybe others here can add more. Jim -- Jim Fulton Zope Corporation From graham.dumpleton at gmail.com Sat Jul 11 13:21:21 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Sat, 11 Jul 2009 21:21:21 +1000 Subject: [Web-SIG] Python hosting (was Re: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open questions on python-dev)) In-Reply-To: References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp> <20090709172515.1801C3A407B@sparrow.telecommunity.com> <4A56CFED.1030505@ar.media.kyoto-u.ac.jp> <3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com> <79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com> <5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com> <02f30a119597a6bbacf2926429f14f67@preisshare.net> Message-ID: <88e286470907110421t7d587da4sc4a2789539569036@mail.gmail.com> 2009/7/11 Jim Fulton : > > On Jul 11, 2009, at 5:58 AM, David Lyon wrote: > >> On Fri, 10 Jul 2009 10:02:39 -0400, Jim Fulton wrote: >>> >>> I was really just pointing out that there isn't >>> anything special about web developers. ?Really the need relates to >>> application development. ?That is, web application developer's needs >>> aren't really different from other application developers' needs. >> >> Just for my own education.. >> >> Why is there so many problems with python hosting? What I mean >> is that any linux host that can run python should be able to >> do web hosting easily. Say like run zope/plone. >> >> Is this due to difficulties in getting packages onto a web host? >> >> What could be done in an ideal world to make it a snap to >> run zope on my cheapy linux web hosting service (that already >> has python)? > > The primary problem is that most web applications require long-running > processes and low-cost hosting providers don't let you run your own > long-running processes. ?My impression is that not many low-cost providers > support mod_python or that perhaps perhaps it's not easy to integrate with > mod_python in those environments. ?I personally haven't tried to run Zope on > low-cost hosting providers. A web hosting company is not going to use mod_python for implementing Python hosting in a shared environment where only one Apache instance is used. This is because it is even more insecure than PHP when using mod_php. In both cases all users code runs as the Apache user. Although for each, each uses code files may be owner by that user and not writable to the Apache user, it will be readable so for a start, any sensitive information of other uses could be read. For PHP the in process code is thrown away at the end of each request, but for mod_python it isn't and is instead retained in memory. Thus, because all user code persistents in memory of same process, technically you could write a C extension plugin that peeks into another users sub interpreter and modifies resident code or again looks at data. Embedding with Python in Apache processes is just terribly insecure and if a web hosting company offers mod_python as a service on a single Apache instance with other users, they have no clue about what they are doing. As such, you should run a long way away. The only way that mod_python works in shared web hosting is where each user is given their own Apache instance, such as is done by WebFaction. Graham > Lots of people are gravitating to Google App Engine, including Zope > developers. ?Zope itself is a bit too heavy for GAE, but lots of Zope > developers are building lighter applications using Zope (and non-Zope) > components. Lots of other frameworks work with GAE. > > Of course, there are lots of relatively low cost (~$20/mo) co-lo providers > that give you a VM you can run anything on. I don't think there're any > problems running Zope in those environments. > > Maybe others here can add more. > > Jim > > -- > Jim Fulton > Zope Corporation > > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > From matt at tplus1.com Mon Jul 13 17:43:28 2009 From: matt at tplus1.com (Matthew Wilson) Date: Mon, 13 Jul 2009 11:43:28 -0400 Subject: [Web-SIG] What is everyone using for URL dispatch? Message-ID: I'm working on a simple webapp I want to run both on GAE and locally. I see GAE has its own URL-dispatching system. I studied selector and routes too. Selector and routes both seem great, but there isn't a whole lot of development activity going on there. Is everyone just rolling their own? Using the ones built into frameworks? Just curious. Matt -- Matthew Wilson matt at tplus1.com http://tplus1.com From maluke at gmail.com Mon Jul 13 18:05:24 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Mon, 13 Jul 2009 19:05:24 +0300 Subject: [Web-SIG] What is everyone using for URL dispatch? In-Reply-To: References: Message-ID: <116315680907130905i13f80389l847996eaefd030da@mail.gmail.com> Things that should cover every URL dispatching need: * WSGI * understanding of script_name / path_info semantics * paste.urlmap.URLMap * webob.Request.path_info / path_info_peek() / path_info_pop() * regulars ifs, splits and dictionary lookups I also use pasteob.PathMap, PathMatch, HostMap, override_https. Works fine for stuff that runs on GAE and elsewhere. On 2009-07-13, Matthew Wilson wrote: > I'm working on a simple webapp I want to run both on GAE and locally. > I see GAE has its own URL-dispatching system. I studied selector and > routes too. Selector and routes both seem great, but there isn't a > whole lot of development activity going on there. > > Is everyone just rolling their own? Using the ones built into frameworks? > > Just curious. > > Matt > > -- > > Matthew Wilson > matt at tplus1.com > http://tplus1.com > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/maluke%40gmail.com > -- Best Regards, Sergey Schetinin http://s3bk.com/ -- S3 Backup http://word-to-html.com/ -- Word to HTML Converter From michael at d2m.at Mon Jul 13 18:16:58 2009 From: michael at d2m.at (Michael Haubenwallner) Date: Mon, 13 Jul 2009 18:16:58 +0200 Subject: [Web-SIG] What is everyone using for URL dispatch? In-Reply-To: References: Message-ID: <4A5B5DFA.3010209@d2m.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Wilson wrote: > I'm working on a simple webapp I want to run both on GAE and locally. > I see GAE has its own URL-dispatching system. I studied selector and > routes too. Selector and routes both seem great, but there isn't a > whole lot of development activity going on there. > > Is everyone just rolling their own? Using the ones built into frameworks? > I am using 'bobo' http://bobo.digicool.com works with GAE too http://blog.d2m.at/2009/06/22/bobo-gae/ Regards Michael - -- http://blog.d2m.at http://planetzope.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKW135l0uAvQJUKVYRAtm5AJ0S1T4iA5u4NofGbGJEfsXCbampUwCffGiu 5K3QJSLgU499wKoLQayn3pc= =d0t4 -----END PGP SIGNATURE----- From ianb at colorstudy.com Mon Jul 13 20:30:22 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 13 Jul 2009 13:30:22 -0500 Subject: [Web-SIG] Developer authentication spec Message-ID: I wrote up a spec a while ago: http://wsgi.org/wsgi/Specifications/developer_auth The goal is a single way to indicate to debugging and developer tools when the developer is logged in. This is orthogonal to normal application authentication. It would control access to things like interactive debuggers, but could also be used to show information about template rendering, profiling, etc. My goal in making this a specification is to encourage wider use of the technique in debugging tools (consumers), so they can use a consistent means of protecting private information or tools intended for developers. Since I wrote the spec I've written up an implementation: https://svn.openplans.org/svn/DevAuth/trunk Last time I brought this up there wasn't any response, but I'm hoping it'll... I dunno, make more sense or seem more interesting now. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From arw1961 at yahoo.com Mon Jul 13 22:07:55 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Mon, 13 Jul 2009 13:07:55 -0700 (PDT) Subject: [Web-SIG] Developer authentication spec Message-ID: <663450.49841.qm@web32008.mail.mud.yahoo.com> I like the general idea of a dev-auth spec. Of course as you know developer mode is extremely dangerous. I would prefer that the spec made getting into developer mode more difficult so that people who don't know what they are doing have to jump through a couple hoops before they hang themselves. Just shoving env['x-wsgiorg.developer_user'] = 'xxx' should not be enough to enable dev mode, and as I read the spec this might be enough. For example the environment value could be required to be an instance of wsgi.DeveloperUser(name) (or whatever) instead of a string so that some bit of Python at least is forced to import the right module and initialize an object before developer mode will work. This will probably be harder to do accidentally from a config file. Alternatively, the spec could say something explicit about the 'client' and the 'server' having a shared secret -- maybe by requiring the client to send a timestamp hashed using a password or something. Any level of safeguard to make it harder for the ignorant innocent bystander sysadmin to shoot himself in the foot might be nice. I'm particularly concerned because as it stands the spec might allow a WHIFF "remote procedure call" to get itself into developer mode automatically, with no password required, unless I add something explicit to prevent it. Just my 2p. -- Aaron Watters === http://aaron.oirt.rutgers.edu/myapp/docs/W1200_1400.stdMiddleware From graham.dumpleton at gmail.com Tue Jul 14 01:59:04 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Tue, 14 Jul 2009 09:59:04 +1000 Subject: [Web-SIG] Developer authentication spec In-Reply-To: References: Message-ID: <88e286470907131659vedd548s4c9cc4d107df2fc3@mail.gmail.com> 2009/7/14 Ian Bicking : > I wrote up a spec a while > ago:?http://wsgi.org/wsgi/Specifications/developer_auth > The goal is a single way to indicate to debugging and developer tools when > the developer is logged in. ?This is orthogonal to normal application > authentication. ?It would control access to things like interactive > debuggers, but could also be used to show information about template > rendering, profiling, etc. ?My goal in making this a specification is to > encourage wider use of the technique in debugging tools (consumers), so they > can use a consistent means of protecting private information or tools > intended for developers. > Since I wrote the spec I've written up an implementation: > https://svn.openplans.org/svn/DevAuth/trunk > Last time I brought this up there wasn't any response, but I'm hoping > it'll... I dunno, make more sense or seem more interesting now. For in browser debuggers, I think a rethink is needed as to how they work. Currently they are only of use if the person who made the request triggered the error and the debugger is enabled. This is useless if you want to debug a problem that happened at an arbitrary time through the actions of an arbitrary user and you don't have a clue how to reproduce it. What I have been wanting to do for a while and just haven't had the time is to develop a debugging package which isn't inline with the request, but is accessed through a special password protected URL, with access restrictions on client IP as well if you want it. The intent was that this be much more than just a code debugger, but a portal into looking at lots of different performance characteristics of an application. The idea for debugging of exceptions is that you would enter this portal and define some criteria as to what you want to capture. For example, you might already know that the problem always occurs when accessing certain URLs. As such, you would set up a definition that says that if an unexpected exception occurs when accessing application through some parent URL, that the exception be caught and the state retained, with the client just getting back the normal 500 error page or other response as appropriate. Because we are going to park the state of the request, we would also define a limit as to how many such events you want to keep as don't want to blow out memory usage or locks on pooled resources. For case where event occurs, you could also be emailed about it so you know about it. As to debugging the problem, later on, or when you get the email, you would login to your debugging portal and view a list of the parked failed requests. You would then select which event you want to debug and would attach to the parked state for that request and the exception state. You would then work in a similar way to the current in browser debuggers. The difference though is that you are debugging an event that happened some time earlier and which was triggered by someone you may not even know. In other words, it is giving you a postmortem facility working on actual data from time of request. This debugging portal could also be expanded to get access to various other information about an application as well using a web page. This is in contrast to a lot of existing stuff which might just dump the information to log files and expect you to look there. For example, you might dynamically through the portal say you want to run profiling of requests against a specific URL. Again, to limit how much data you capture, you might say to do it only once, a small set number of times, or for a period of time. The profiling data for this might be retained in memory, or written to disk, but either way, the web interface provided by the portal would be the means of viewing it. Other things that the debugging portal could provide is: - Ability to capture request and response details, optionally including request and response content, for later analysis or replay. - Recording time taken for specific requests. - For a multithreaded process, capture some metrics on thread pool utilisation. That is, the average and maximum number of threads being used over time. The intent here being used to determine how many threads are actually required to handle your request load so that can drop number of threads and reduce memory usage. - Track requests/second. - etc etc etc With all these, they should be able to applied to all or sub sets of URLs. You should be able to specify some criteria as to how long you run the data probe, ie., number of requests, set time, forever. You should perhaps be able to filter based on IP of remote client etc etc. The final thing is that these shouldn't be developed as lots of separate applications, but a framework constructed which would allow different developers to implement them as component instruments that could then be added as plugins into the debugging portal and mesh nicely with the overall web page theme for the portal. The intent with this debugging portal is that it could always be a part of a production application. Most of the time it would be off to the side, idle and having negligible if any performance impact. When you do have a problem, then you would go set up the probe you want run and leave it. You then come back when you want and review the results. For some types of probes the overhead may be minimal enough that you could even leave them on all the time, Because it would be part of the production application, the debugging framework itself should not be too heavy weight, so, it should not be dependent on running some large high level framework. Instead, it should be quite small and based on WebOb or similar. Because of its simplicity, bobo might be a good choice for URL dispatch, for which you get WebOb anyway. For templating where necessary, not sure. Personally, I actually think it should try and use AJAX and push the application interfaces back into Javascript on the browser, with remote calls using JSON to interact with the actual engine. Pyjamas could be a good match for developing the interface. What problems would there be. Well, the main one is that due to retained state being kept for debugging sessions, WSGI application needs to be run in one process. So, may not be as useful for multiprocess deployments. Even then, using stick sessions/session affinity using cookies one might be able to at least monitor a selected process in a multiprocess configuration. You might even build on the deployment mechanisms to some how dynamically skew traffic towards that specific process when you do want to do some data measurement. Anyway, lots of ideas but no time. I had sort of seen this as a project I might develop myself, but due to that lack of time, maybe the above description might inspire others to see what it is I am thinking of and the possible utility of it. As such, maybe some of you out there may be interested in doing this as a group project. If not, I'll park the idea again and come back to it when I have time. Graham From christian at dowski.com Tue Jul 14 05:01:24 2009 From: christian at dowski.com (Christian Wyglendowski) Date: Mon, 13 Jul 2009 23:01:24 -0400 Subject: [Web-SIG] What is everyone using for URL dispatch? In-Reply-To: References: Message-ID: On Mon, Jul 13, 2009 at 11:43 AM, Matthew Wilson wrote: > I'm working on a simple webapp I want to run both on GAE and locally. > I see GAE has its own URL-dispatching system. ?I studied selector and > routes too. ?Selector and routes both seem great, but there isn't a > whole lot of development activity going on there. > > Is everyone just rolling their own? ?Using the ones built into frameworks? I'm guessing that Routes and Selector might be close to "done". They both work well AFAIK. Active development isn't a great indicator of how useful a library is. Christian Wyglendowski http://www.dowski.com From wilk at flibuste.net Tue Jul 14 09:46:49 2009 From: wilk at flibuste.net (William Dode) Date: Tue, 14 Jul 2009 07:46:49 +0000 (UTC) Subject: [Web-SIG] Developer authentication spec References: <88e286470907131659vedd548s4c9cc4d107df2fc3@mail.gmail.com> Message-ID: On 13-07-2009, Graham Dumpleton wrote: > 2009/7/14 Ian Bicking : >> I wrote up a spec a while >> ago:?http://wsgi.org/wsgi/Specifications/developer_auth >> The goal is a single way to indicate to debugging and developer tools when >> the developer is logged in. ?This is orthogonal to normal application >> authentication. ?It would control access to things like interactive >> debuggers, but could also be used to show information about template >> rendering, profiling, etc. ?My goal in making this a specification is to >> encourage wider use of the technique in debugging tools (consumers), so they >> can use a consistent means of protecting private information or tools >> intended for developers. >> Since I wrote the spec I've written up an implementation: >> https://svn.openplans.org/svn/DevAuth/trunk >> Last time I brought this up there wasn't any response, but I'm hoping >> it'll... I dunno, make more sense or seem more interesting now. > > For in browser debuggers, I think a rethink is needed as to how they > work. Currently they are only of use if the person who made the > request triggered the error and the debugger is enabled. This is > useless if you want to debug a problem that happened at an arbitrary > time through the actions of an arbitrary user and you don't have a > clue how to reproduce it. ... Great project ! We should not forget the possibility of a server without access, or a server wich will be restarted. I mean that the state should be transportable. Currently, when my server catch an exception, it send the most it can to an url (traceback + logs). On this url i record the data and send an email. -- William Dod? - http://flibuste.net Informaticien Ind?pendant From t.koutsovassilis at gmail.com Sun Jul 19 18:18:17 2009 From: t.koutsovassilis at gmail.com (Tassos Koutsovassilis) Date: Sun, 19 Jul 2009 16:18:17 -0000 Subject: [Web-SIG] Porcupine Web Application Server 0.6 released Message-ID: <4A634740.9070105@innoscript.org> I'm pleased to announce the new version of Porcupine Web Application Server, a Python based framework that provides front-end and back-end technologies for building modern data-centric Web 2.0 applications. During the past months, I have put a lot of effort for making this release finally available. It includes a new whole bunch of new features and improvements, mainly aimed towards scalability. The server now supports multiple processes by using the "multiprocessing" module firstly introduced in Python 2.6. The Porcupine database now supports indexes declared at a server-wide scope inside the Porcupine configuration file (porcupine.conf). Currently, the indexes are used for common database usage patterns such as getting the children of a container, but not yet fully leveraged by OQL. For the time being, simple queries like select something from 'container_id' where indexed_attribute=value will leverage the index structure. The Etag HTTP header is now fully supported for static files. For dynamic requests a new pre-processing filter is included that allows conditional Etags, meaning that an Etag header will be generated only if a user predefined condition is true. The Porcupine API is partially aligned with PEP 8. The majority of the API calls are no longer camelCase and such calls are considered deprecated (i.e. the Container's getChildren method is now get_children). Check the server's log thoroughly for deprecation warnings and make the appropriate changes. QuiX, the server's integrated JavaScript toolkit, has reached the major milestone of supporting all the popular browsers including Opera, Safari 4 and IE8. The structure of the QuiX API has been re-factored by introducing JavaScript namespaces (i.e. XButton has become QuiX.ui.Button, XMLRPCRequest has become QuiX.rpc.XMLRPCRequest). Of course backwards compatibility is still preserved in order not to break the existing code. The redraws have been accelerated by using some sort of internal cache mechanism that prevents the core from calculating the same widget parameter twice. Another great feature combined with the server side Etag support is the ability to persist data sets on the browser side. For accomplishing this kind of functionality QuiX includes PersistJS (http://pablotron.org/?cid=1557), a lightweight persistence library, that uses the appropriate persistence mechanism for different browsers including Google Gears, globalStorage, localStorage, openDatabase etc. Auto-sized widgets are now finally supported. Their size is automatically adjusted based on their contents. Widgets supporting this kind of feature include labels, icons, buttons and boxes. Auto sized boxes require all their children to have fixed sizes or being auto-sized themselves. Another important improvement is a universal base Widget implementation that now allows integration with non-Porcupine web applications more easily. Other notable new features and improvements include themes support for QuiX, new optimized transactions, a lightweight rich text editor, new cookie based and database session managers (required for multi-processing setups) and a new Shortcut content class. Helpful links ============ What is Porcupine? http://www.innoscript.org/what-is-porcupine-web-application-server/ Online demo: http://www.innoscript.org/porcupine-online-demo/ Downloads: http://www.innoscript.org/porcupine-downloads/ Documentation: http://www.innoscript.org/documentation/