Chris McDonough wrote: > I've been working on a new web framework named (provisionally) repoze.bfg. > > The relevant README is here: http://svn.repoze.org/repoze.bfg/trunk/README.txt > > It is essentially a "Zope lite". It is Zope-ish in that: > > - it uses a lot of Zope libraries and concepts (interfaces, some CA > constructs, > ZCML) > > - it uses graph-traversal-based URL dispatch. > > - by default it provides ZPT (actually z3c.pt) templates. > > - it provides built-in authorization facilities based on permissions > and users/groups. > > It is unlike Zope (variously 2 or 3) inasmuch as: > > - It uses a different publisher and authorization model. > > - It is heavily dependent on WSGI. > > - Its equivalent of the publisher doesn't attempt to traverse into > *code* stored in the object graph. All code is on the filesystem. > The only thing in the object graph is "model" data. > > - It doesn't attempt to provide any server functionality. This duty is > left over to WSGI. > > - It doesn't provide *authentication* functionality (just authorization > functionality). Authentication is left up to upstream server/middleware > (e.g. repoze.who). > > - It's not meant to be "plugged in to". A repoze.bfg application is not > a plugin to repoze.bfg (e.g. it's not a Zope2 Product). Instead, a > repoze.bfg application is just a Python package that happens to use > repoze.bfg facilities. > > - The graph root is not effectively assumed to be a ZODB database. > > - It provides no built-in through-the-web management interface. > > It's unlike Grok inasmuch as: > > - It doesn't try to hide ZCML for configuration. > > If I were to characterize it succintly and informally, I migh say it's a bit > like Django built around graph traversal dispatch instead of URL-based > dispatch. > > Speed is a priority. A "hello world" template is currently clocking in at > around 550 req/sec on my MacBook (including security lookups). > > It's my intent to continue to develop it, along with a package named > "repoze.lemonade", which will integrate repoze.bfg with ZODB and provide > various > persistence-related features (folders, object events, indexing and so forth). > > In any case, I thought maybe some folks would be interested in > using/contributing to it. It can be checked out via: > > svn co http://svn.repoze.org/repoze.bfg/trunk/ > Hi Chris,
This is very interesting, really. I'm going to steal many of your ideas ;). Incidentally, we're both developing something similar at the same time. It seems to me that repoze.bfg's goals are pretty similar to Rum's [1] and repoze.lemonade looks like the ZODB cousing of RumAlchemy, but we're taking different approaches so there's room for both in the web-micro-framework world :) For example, bfg's URL dispatch seems more sophisticated and is probably more powerful than Rum's since I'm using Routes to do the heavy url-dispatching lifting and I'm only planning to handle two level deep hierarchies (ie: /persons/6/addresses) which is good enough I think to publish objects mapped by an ORM since you can always reach any object this way (provided you PKs in all the tables you want to publish). Another big difference is that instead of formal interface adaptation I'm implementing similar functionality with peak.rules' generic functions (mainly because I've never really used the former so I'm sticking to what I have experience with for now). I'm also planning to implement row-level authorization (using peak.rules) in a similar way to yours as I've grasped from a quick glance at your API. All in all, it's good to know that both designs are somewhat similar (now I know I'm not too far from the right track :) but different enough in such a way we can both go in out own direction without feeling guilty about it ;) After all, we'll be sharing lots of code anyway (webob, paste and repoze.tm2 at least). Looks like the "wsgi community" is getting very hot this summer, I can't wait to see what the next months will bring! :) Cheers, Alberto [1] http://toscawidgets/documentation/rum is the closest thing to an official website ATM. _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
