[Zope-dev] Redirect Exception and Five
Hi all, I have a problem developing a Product using Five.When a Redirect Exception is raised from a PluggableUserFolder inside my product, it is not handled by the publisher, and I have an error message instead a browser redirect. The same test inside a normal Folder works fine. I'm using Zope 2.9.0, and tried to add this ZCML statements, but I've no luck, and I can't find any other message talking about this. Anybody knows what could happen ? Thanks -- Santi Camps Earcon S.L. - http://www.earcon.com - http://www.kmkey.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: http access to svn repos?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Would anyone be averse to making anonymous http checkouts possible from zope.org? Some of us are behind annoying proxies that won't let svn through :-/ At one point, enabling the 'http:' checkout gateway was a sure-fire recipe for getting SVN's knickers in a twist, which is why we disabled it. Or maybe that was ViewCSV. Actually, it was BekeleyDB. :) The main obstical was that it required apache 2 and, at the time we were running apache 1 and I didn't want to spend the time figuring out the apache access. In any case, I would guess that you might persuade folks to allow DAV-based checkout (which is what svn-over-http is), but you are likely to have to write it up as a proposal, including specific information about the Apache / SVN configuration changes required. PS: https write access would be nice, but I guess that's out of the question? Yes, definitely. The answer is the same as when you asked for it two years ago (: the WebDAV stuff is slow (which may be a reason not to allow annonymous http: checkouts, too), and the credentials mechanism is built entirely around the contributor's SSH key.. I would support HTTP anonymous checkouts. I'm really against writable HTTP checkouts because I consider the credentials mechanism for HTTP access to be extremely lame. Despite out lame program for uploading keys, I find the ssh-based access mechanism to be far more usable and secure. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] http access to svn repos?
Chris Withers wrote: Hi All, Would anyone be averse to making anonymous http checkouts possible from zope.org? Not in principle. In fact, I would find it convenient for a particular project. I doubt that anyone with access to that machine has time, \ although I can only speak for myself. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Two visions
On Mar 6, 2006, at 9:21 PM, Jake wrote: I think it is a huge mistake to lose Zope branding. After years of building up momentum behind a project, to head off into some strange developer code speak is just going to lose people who are not intimately involved. The world, after many years, gets versions. Stick to it. Works: Mac OS9 -> Mac OSX (10) Here was a mistake: Mosaic -> Netscape -> Netscape Communicator -> Netscape Gold -> Firebird -> Mozilla -> Firefox Considering Firefox has nearly 15% marketshare today, I'd call it a success. It certainly could have been worse had Netscape not done the hail mary of releasing it under another name that wasn't conflated with its own brand (witness the takeup rate of Netscape 6/7). - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Principles
Hi there, Geoff Davis wrote: I am very glad to see that Jim's efforts to better articulate a vision for Zope have generated so much interest. I am not so sure that the discussion has been an entirely productive one. I think that we as a community would benefit by working on our social engineering as much as our software engineering. Heh. Yeah. :) [snip] One of the things that GTY recommends is to establish a set of agreed upon principles for evaluating proposals. I think that having such a set of principles would help us better focus our current discussion. Agreed. Let's take a step back from the particulars of the various proposals floating around and see if we can nail down some principles. Here is a very rough, very incomplete start: One thing about these principles is weight. Even if we all agree, some may think one principle is more important than another. Should one principle be able to trump another one? 1. Zope should have a clear message about where we are going. I'm sure we all agree on this, but this is so broad that it is not very useful. Here's a stab at refining it: 1.1 We should have a clear message about where Zope 2 is going. The message should give existing and prospective Zope 2 users an idea of how long their code will continue to work on releases in the Zope 2 path and what kind of upgrade process they will face as the Zope 2 line evolves. 1.2 Ditto for Zope 3. +1 2. Zope should try to expand its developer base. Again, I am sure we all agree, but this is too broad to be useful. 2.1 Zope should leverage the work of others by moving toward an architecture that allows one to easily use code from outside Zope. +1 This effectively increases the developer base by letting us leverage the work of others outside the immediate Zope community. I assume that this (and integration) are the primary motivations driving the CA. I don't think that's the only motivation driving the CA. A very important motivation of the CA in my book is extensibility and evolution. Using the CA makes it easier to evolve existing codebases by extending them in all kinds of ways. 2.2 Zope should be useful for developers not using the full application server stack. > Again, this serves to increase our developer base by drawing in people > outside our traditional core audience. +1 I'll add a few related principles that have a different perspective: * Zope should aim not to reinvent the wheel. Instead we should leverage code outside of Zope in Zope itself. * Zope should play friendly with the Python community * We want to engage the Python community and use Python community code, engaging in non-zope communities. * We want the Python community to use more code spun off Zope, and have them engage into our community. And one more that came up a lot: * We want to cater better to a set of developers left in the cold by Zope 3. We probably need some principles about the Zope brand, and so on, but I think this should serve as a useful starting point. * We want the strengthen the brand of our software. * of the software we call Zope 2 * of the software we call Zope 3 * of the components that Zope 3 is composed of * We want to strengthen the brand named Zope. * the Zope 2 brand. * the Zope 3 brand. * the Zope without 2 or 3 brand. * We want to use the strengths of the Zope brand in our communication. * We want to capitalize on technical strengths. * We want to capitalize experience and maturity. * Extended CMS features. * We want to counter the weaknesses of the Zope brand. * We want to counter the crufty, overly complex reputation that Zope has in the Python community. * We want to counter the reputation in the Python community that Zope is off on its own. * We want to avoid the weaknesses of the Zope brand. * In particular, the cruftly, overly complex reputation that Zope has in the Python community. * We don't want to weaken the Zope brand. * We don't want to give the impression we promise features that we end up not delivering. * We don't want to give the impression we promise features soon that we end up delivering only very much later. Note that these principles can all lead to quite different conclusions, but it's indeed good to articulate them. Let's see if we can expand and refine these principles before going down the "vision" road. I think that we will find that once we have articulated a set of core principles, defining a vision that adheres to them will be much easier. Very good initiative! I'll leave it up to you Geoff to see whether you want to adopt some of the principles I listed in a larger document and give them a canonical number. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman
[Zope-dev] Re: http access to svn repos?
Tres Seaver wrote: Where should I write the proposal? Who is going to review it? http://www.zope.org/Wikis/DevSite/Proposals ; post here and zope3-dev for review. yay! a wiki... oh the joy... You need to identify potential issues, document any changes needed to the Apache config (to enable the DAV verbs, for instance), and spell out how to revert it; then get the rest of the community to accept it, at least tacitly. *sigh* red tape wins again. It's much easier to just do nothing, and just not be able to contribute from behind a firewall... The issues aren't so much technical feasibility as social / legal: a checkin done using somebody's private key is way less deniable than one done with a password. Unless you plan to set up a system for issuing client certificates to contributors, I don't think https is superior to svn+ssh at all. Hmmm, I'm tempted to call BS on this. How much of this has actually been tested in a court? Really, all this crap gets caught up on pseudo legal BS which ultimately just makes it more difficult for people to contribute :-( I really don't get the whole paranoia about passwords anyway... yes, client certs and public key are "more secure", but really, why are we setting the bar so high? It's not like we're dealing with top secret national security stuff... yes, this sucks :-/ It's *by design*. OK, as a concrete example, the guys at my current big project have effectively donated a full MSDN license so I can pick up doing the Windows builds and give Tim a break. But, because they're a bank, they care about security and so don't let any old protocol through their firewalls... http and https are fine, I can check into or out of my own repository, and any other repo running a "standard" protocol. However, zope.org insists on using the esoteric svn+ssh protocol for write access (which you have to jump through all sorts of hoops to get working on Windows anyway :-/) and the getting-used-less-and-less svn protocol which is just flat blocked by large and immovable firewalls... For trying to get people to help out, this sucks ass. Come on, we're an open source project, we _want_ people to help out, not keep on pushing them away with higher and higher bars :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
