On 5/12/09 7:15 AM, Hanno Schlichting wrote: > Hi. > > I've started to play around with repoze.zope2 trunk as witnessed on the > commit list. > > What I'm trying to do here is to remove the last dependencies of > repoze.zope2 to ZPublisher code. For the most part these are the request > and response objects. > > My goal is to clean up both of these classes and aim for something like > a 80% backwards compatibility for used-in-the-wild code. My current > definition of used-in-the-wild is a very narrow "used anywhere in the > Zope2, CMF, PAS, Plone" stack. If I only find a specific API used once > in that entire stack, I tend to change that one occurrence if there's an > equivalent more wildly used API around.
I think this package is becoming less "repoze.zope2" than some other more experimental system. Which is fine. But there's no way I'm going to be able to give people help with it on IRC or the maillist when it breaks because they're using an API that we removed. I have more fun things to do. ;-) FTR, the cruft-removal-at-all-costs goal is not the goal of the original version of repoze.zope2. The original goal was 100% compatibility with existing applications. The reason I started BFG was because I thought losing b/w compat with stock Zope 2 was an antigoal. It just doesn't seem to be a win to innovate and make bold changes in order to get a still-horribly-crufty system, but which now isn't even backwards compatible. If we ever do release an 80%-compatible publisher replacement, we should call it something other than "repoze.zope2". > If I'm lucky I might be able to: > > - Trim down the API's to a reasonable level > - Remove cruft from the early Bobo-Times > - Avoid duplication of code in the z2bob helper > - Base both classes on WebOb > - Handle Unicode and WSGI more sanely > What I'm *not* trying to do is to make the request and response more > similar to the zope.publisher variants. Whatever API's or functionality > the ZPublisher versions haven't gotten so far, doesn't strike me as > particular useful. +1 > > The WebOb thing is the last step on my list. I'll only do that if it > actually provides any kind of reasonable code reduction or makes the > z2bob code easier. If mixing in WebOb would only add a second API in > addition to the existing one, it's probably not worth it. +1 - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
