Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On Sat, May 16, 2009 at 10:47 AM, Chris McDonough wrote: > On 5/16/09 6:58 AM, Hanno Schlichting wrote: > > Tres Seaver wrote: > >> +lots to calling this something other than 'repoze.zope2', which has > >> always been about bending over backward to provide full BBB for Zope2 > apps. > > > > What about calling it repoze.z2bob? > > > > It's still a bob (based on repoze.obob) helper for Zope 2, but in spirit > > closer to the bob (as in simplification) story than the Zope 2 story. > > I'd still rather not have "repoze" in it's name if it sees the light of day > as a > release. > > plone.publisher? Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On 5/16/09 6:58 AM, Hanno Schlichting wrote: > Tres Seaver wrote: >> +lots to calling this something other than 'repoze.zope2', which has >> always been about bending over backward to provide full BBB for Zope2 apps. > > What about calling it repoze.z2bob? > > It's still a bob (based on repoze.obob) helper for Zope 2, but in spirit > closer to the bob (as in simplification) story than the Zope 2 story. I'd still rather not have "repoze" in it's name if it sees the light of day as a release. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
2009/5/16 Hanno Schlichting : > What about calling it repoze.z2bob? If Plone is your development target, perhaps just call it ``repoze.plone``. In terms of "scratching your own itch", I think it fits amicably with your intentions. You're not trying to improve Zope 2––rather, you're trying to provide a sane platform for Plone. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
Tres Seaver wrote: > +lots to calling this something other than 'repoze.zope2', which has > always been about bending over backward to provide full BBB for Zope2 apps. What about calling it repoze.z2bob? It's still a bob (based on repoze.obob) helper for Zope 2, but in spirit closer to the bob (as in simplification) story than the Zope 2 story. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On May 13, 2009, at 3:40 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chris McDonough wrote: >> On 5/12/09 12:00 PM, Malthe Borch wrote: >>> 2009/5/12 Chris McDonough: If we ever do release an 80%-compatible publisher replacement, we should call it something other than "repoze.zope2". >>> I doubt if we're really talking 80% though; if as Hanno suggests, >>> it'll run CMF, Plone and what other popular Zope 2 apps/libraries, >>> isn't it more like 95%? In that case, I think the name can remain >>> the >>> same. >> >> Since those systems don't have any well-understood APIs themselves >> (at least >> historically), apps written on top of them do plenty of arbitrary >> things. >> Putting some 80% thing out there and telling folks "Plone and CMF >> run on it" >> without some "porting guide" is a recipe for endless maillist >> conversations with >> people not-in-the-know... "but now I get this KeyError in this app >> code I >> inherited four years ago... can you help me?" . >> >> Breaking certain arbitrary things is fine, but maybe for such a >> thing to match >> the goals of the original "repoze.zope2", there has to be a widely- >> published >> list of each backwards incompatibility, showing "real world" >> symptom of a >> breakage and providing a workaround. Doing a good job at >> documenting breakage >> symptoms and workarounds is usually far more work than actually >> doing the coding >> to rip out some feature (I find it usually takes about 4X as long). >> >> If we can't afford this (and I sure can't personally), I'm not sure >> what we'd >> end up calling it. plone.dot.someting? zope.dot.something? > > +lots to calling this something other than 'repoze.zope2', which has > always been about bending over backward to provide full BBB for > Zope2 apps. repoze.plope has a nice ring to it ;^) -Casey ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: > On 5/12/09 12:00 PM, Malthe Borch wrote: >> 2009/5/12 Chris McDonough: >>> If we ever do release an 80%-compatible publisher replacement, we should >>> call it >>> something other than "repoze.zope2". >> I doubt if we're really talking 80% though; if as Hanno suggests, >> it'll run CMF, Plone and what other popular Zope 2 apps/libraries, >> isn't it more like 95%? In that case, I think the name can remain the >> same. > > Since those systems don't have any well-understood APIs themselves (at least > historically), apps written on top of them do plenty of arbitrary things. > Putting some 80% thing out there and telling folks "Plone and CMF run on it" > without some "porting guide" is a recipe for endless maillist conversations > with > people not-in-the-know... "but now I get this KeyError in this app code I > inherited four years ago... can you help me?" . > > Breaking certain arbitrary things is fine, but maybe for such a thing to > match > the goals of the original "repoze.zope2", there has to be a widely-published > list of each backwards incompatibility, showing "real world" symptom of a > breakage and providing a workaround. Doing a good job at documenting > breakage > symptoms and workarounds is usually far more work than actually doing the > coding > to rip out some feature (I find it usually takes about 4X as long). > > If we can't afford this (and I sure can't personally), I'm not sure what we'd > end up calling it. plone.dot.someting? zope.dot.something? +lots to calling this something other than 'repoze.zope2', which has always been about bending over backward to provide full BBB for Zope2 apps. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKCz5K+gerLs4ltQ4RAgxAAJ9XhD7rEROlUWZVrt6nl40coB3yRACfXMs6 gsAtcLTDwybdFmsbpquMJcE= =doWK -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
Reed O'Brien wrote: > On May 12, 2009, at 12:17 PM, Chris McDonough wrote: >> If we can't afford this (and I sure can't personally), I'm not sure >> what we'd >> end up calling it. plone.dot.someting? zope.dot.something? > > ymmv.zope2 LOL! It would be a commitment to never commit to anything. :-) Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
Chris McDonough wrote: > I added some more test coverage on the trunk. It's still pretty poor right > now. Awesome! I'll try to improve the coverage after getting some more documentation for my latest changes in. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On 5/12/09 11:54 AM, Hanno Schlichting wrote: > Chris McDonough wrote: >> 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". > > I don't particularly care about names of anything at all here. > > repoze.zope2 seems to be the closest thing out there which allows me to > move in some form of evolutionary approach from current Plone/Zope2 to > something that has a reasonable chance of loosing its Zope2 > underpinnings before hell freezes over. > > I still think the general goal is to decompose things and use WSGI for > this package, so it fits the Repoze umbrella. If you have a suggestion > on what to name it instead, that'd be more than welcome - don't let > Germans name anything ;) > > Hanno I added some more test coverage on the trunk. It's still pretty poor right now. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On 5/12/09 9:35 AM, "Malthe Borch" wrote: > 2009/5/12 Andrew Sawyers : >> Just and FYI from a (large) consumer of the repoze.zope2 package >> This kind of change causes expensive test iterations. We're currently going >> through one now...as a result of choosing to move over to repoze.zope2 and >> friends. We would like to continue consuming this project work but to >> recommend another (expensive) test iteration to find out our app definitely >> runs on the next iteration would make us rethink our decision. > > You could peg your version and choose not to upgrade. > > \malthe We would choose to upgrade if Chris' position were followed; so that's -1 IMNSHO. Andrew ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
2009/5/12 Andrew Sawyers : > Just and FYI from a (large) consumer of the repoze.zope2 package > This kind of change causes expensive test iterations. We're currently going > through one now...as a result of choosing to move over to repoze.zope2 and > friends. We would like to continue consuming this project work but to > recommend another (expensive) test iteration to find out our app definitely > runs on the next iteration would make us rethink our decision. You could peg your version and choose not to upgrade. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On May 12, 2009, at 12:17 PM, Chris McDonough wrote: > On 5/12/09 12:00 PM, Malthe Borch wrote: >> 2009/5/12 Chris McDonough: >>> If we ever do release an 80%-compatible publisher replacement, we >>> should call it >>> something other than "repoze.zope2". >> >> I doubt if we're really talking 80% though; if as Hanno suggests, >> it'll run CMF, Plone and what other popular Zope 2 apps/libraries, >> isn't it more like 95%? In that case, I think the name can remain the >> same. > > Since those systems don't have any well-understood APIs themselves > (at least > historically), apps written on top of them do plenty of arbitrary > things. > Putting some 80% thing out there and telling folks "Plone and CMF > run on it" > without some "porting guide" is a recipe for endless maillist > conversations with > people not-in-the-know... "but now I get this KeyError in this app > code I > inherited four years ago... can you help me?" . > > Breaking certain arbitrary things is fine, but maybe for such a > thing to match > the goals of the original "repoze.zope2", there has to be a widely- > published > list of each backwards incompatibility, showing "real world" symptom > of a > breakage and providing a workaround. Doing a good job at > documenting breakage > symptoms and workarounds is usually far more work than actually > doing the coding > to rip out some feature (I find it usually takes about 4X as long). > > If we can't afford this (and I sure can't personally), I'm not sure > what we'd > end up calling it. plone.dot.someting? zope.dot.something? ymmv.zope2 > > - C > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
On 5/12/09 12:00 PM, Malthe Borch wrote: > 2009/5/12 Chris McDonough: >> If we ever do release an 80%-compatible publisher replacement, we should >> call it >> something other than "repoze.zope2". > > I doubt if we're really talking 80% though; if as Hanno suggests, > it'll run CMF, Plone and what other popular Zope 2 apps/libraries, > isn't it more like 95%? In that case, I think the name can remain the > same. Since those systems don't have any well-understood APIs themselves (at least historically), apps written on top of them do plenty of arbitrary things. Putting some 80% thing out there and telling folks "Plone and CMF run on it" without some "porting guide" is a recipe for endless maillist conversations with people not-in-the-know... "but now I get this KeyError in this app code I inherited four years ago... can you help me?" . Breaking certain arbitrary things is fine, but maybe for such a thing to match the goals of the original "repoze.zope2", there has to be a widely-published list of each backwards incompatibility, showing "real world" symptom of a breakage and providing a workaround. Doing a good job at documenting breakage symptoms and workarounds is usually far more work than actually doing the coding to rip out some feature (I find it usually takes about 4X as long). If we can't afford this (and I sure can't personally), I'm not sure what we'd end up calling it. plone.dot.someting? zope.dot.something? - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
2009/5/12 Chris McDonough : > If we ever do release an 80%-compatible publisher replacement, we should call > it > something other than "repoze.zope2". I doubt if we're really talking 80% though; if as Hanno suggests, it'll run CMF, Plone and what other popular Zope 2 apps/libraries, isn't it more like 95%? In that case, I think the name can remain the same. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
Chris McDonough wrote: > 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". I don't particularly care about names of anything at all here. repoze.zope2 seems to be the closest thing out there which allows me to move in some form of evolutionary approach from current Plone/Zope2 to something that has a reasonable chance of loosing its Zope2 underpinnings before hell freezes over. I still think the general goal is to decompose things and use WSGI for this package, so it fits the Repoze umbrella. If you have a suggestion on what to name it instead, that'd be more than welcome - don't let Germans name anything ;) Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zope2 - what's up on trunk
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
[Repoze-dev] repoze.zope2 - what's up on trunk
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. 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. 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. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
