Alberto Valverde wrote:
> 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 
> 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 :)
Wow. All the files have the same names! I think that means we're converging on
consensus... ;-) Very readable code.
> 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).
There's a long mea culpa in the repoze.bfg README.txt about graph traversal vs.
URL-dispatch (ala Routes). Graph traversal over "model" data doesn't really
make much sense when your model data is square, only when it's (arbitrarily)
We tend to like graph-traversal based lookup because it feels natural to
associate security declarations with (persistent) nodes in the graph, and the
resulting application is usually pretty easy to understand and performs well.
But it's not for everyone, by a long shot.
I suspect the ultimate answer if there's ever a point where you'd care about
both square and arbitrarily hierarchical data would to be able to use both URL
dispatch mechanisms and combine them as necessary. Actually, that wouldn't be
too hard to do.. just let Routes take a crack at resolving a URL before the
graph traversal stuff kicks in.
> 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 think it's about the same thing. Like you, I used what I knew. It'd be nice
to see generic functions in Python.
> 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.
I'll definitely be interested to see that. I can't quite wrap my brain around
how that might work in the multitable join case.
> 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).
Woot! I suspect we could probably share more. Particularly if we gave Routes
crack at the dispatch first.
> Looks like the "wsgi community" is getting very hot this summer, I can't
> wait to see what the next months will bring! :)
Repoze-dev mailing list