Re: [Zope-dev] Defining Zope 3.
On 4/20/09 3:35 AM, Martijn Faassen wrote: Stephan Richter wrote: On Sunday 19 April 2009, Tres Seaver wrote: -1. As a branding choice (as opposed to a technology), Zope 3 *is* a dead-end: it implies a strategy (replacing Zope 2) which we no longer believe in. I think the consequences of the brand confusion are hard for those uf us inside to estimate, but they are far from trivial. I never communicated to anyone that I believe that Zope 3 is a successor of Zope 2. Other people pushed that message. That message has been out there from the start, no matter how it arose. One way this conclusion was reached was the obvious 3 versus 2. We need to fix that situation. I think Martijn's right on this point. FWIW, there was a mailing list setup to discuss this when it came up in Jan 2003: http://archives.free.net.ph/mindex/zope2-migrat...@20021201.05..en.html Here's a useful thread showing a dialog between Seb Bacon, Jim, and me: http://archives.free.net.ph/message/20030214.073424.f58e0929.en.html We have arrived at a different result, of course, but it is still useful to agree on the background. We also had the discussion when the decision was made to drop the X in Zope 3X, without fulfilling one part of the bullet points for why there was an X. Stephan, I agree that you didn't communicate that message. But I think it is pretty easy to show that Zope communicated that message, officially and unofficially. --Paul ___ 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] the Zope Framework project
On 3/4/09 1:07 AM, Chris McDonough wrote: Martin Aspeli wrote: Chris McDonough wrote: Sorry, the you above in you scolded was Martin Aspeli, not Faassen. Note that the scolding had something to do with you breaking Plone trunk due to a transitive change in Chameleon, and the realisation that from this point on, any package shared between repoze.bfg and Plone (or anything else) that is configured with ZCML, will probably need to be forked. We found a workaround with Chameleon, but not one that will scale. The fix is totally scalable and completely correct. Chameleon.zpt just does not have any (real) ZCML anymore. Any package that has ZCML is, by definition, written for some framework as stuff that is meant to be overridden, otherwise it wouldn't be written as configuration. ZCML is unlike code in this way. If it wasn't meant to be overridden, it would be in code. All packages which are meant to be maximally useful outside the scope of that framework should be split into two things: the library portion, then some portion that contains ZCML for gluing in to some framework that wants ZCML in some specific configuration. When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! Package sharing between repoze.bfg and Plone should not mean that BFG gets dragged down, paying for things it specifically doesn't want to eat. BFG never claimed to sign up for Plone's contracts. I sense the logic of Chris's position: if the Zope Framework is as big as every current use case in Zope2+Zope3+Grok+etc., with nine years of accumulations on each (3 forms systems in one of them), then we're missing the goal (IMO). We'll make life incrementally better for ourselves, but we'll still scare off the folks who aren't after Uberthing. Plone is going towards a smaller-and-smaller core that is only as big as the manpower to do a great job at keeping it stable. Meaning, very small. Hopefully the Zope Framework is a tiny little thing that pays only for what it eats. Hopefully the goal is to make a very good microframework (or even better, set of libraries). If you can't make the best configuration language possible because one line of includes to get trusted adapters is an unconscionable burden is the rule, then I know how this movie ends. --Paul ___ 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] the Zope Framework project
On 3/4/09 8:16 AM, Martin Aspeli wrote: Paul Everitt wrote: When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! In this case, you totally misread my post. It broke for all users of zope.component, and I never, once, made the argument that Chameleon was part of Plone or should be driven purely by Plone's needs. I have no such pretentions, nor does anyone else I know, about this, or zope.* or the CMF package or, well, anything that is not expressly part of Plone. Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ 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] the Zope Framework project
On 3/4/09 9:47 AM, Roger Ineichen wrote: Hi Paul Betreff: Re: [Zope-dev] the Zope Framework project On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. I agree, and I think this case is a good exemplar for the challenge. Chameleon wanted to make a good templating engine that was independent of megaframeworks. For that, it needed/wanted a configuration language that met your statement I don't like to have any code...I don't use. But legacy in one of the projects changed this from a self-contained, 1x amount of work into a cobweb of bigger issues, control in the hands of others, and 10x the work. Human nature says that's demoralizing. Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. --Paul ___ 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] the Zope Framework project
On 3/2/09 10:13 PM, Martin Aspeli wrote: We recognised that there was a problem in trying to make sure we represented the interests of various stakeholders, and that we needed someone to think big picture in terms of what technologies we adopted and how we used them. Just to be clear, I believe the Plone framework team has specifically disavowed management of Plone's strategy. Meaning, they approve PLIPs on a release-to-release basis. They don't make edicts like replace Archetypes. This was the vacuum that the strategic planning summit advertised itself as addressing. I think this clarification is informative to Martijn's discussion. --Paul ___ 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] the Zope Framework project
On 3/2/09 6:36 PM, Martijn Faassen wrote: Hi there, To people who are suggesting we don't need a steering group nor a name for the Zope Framework, please answer the following questions: * how will the community make hard decisions where lots of people disagree? What is the mechanism for making hard decisions? Don't say Jim makes them because as you may have noticed Jim *hasn't* been making so many of those in recent times. We need to solve this problem. Ultimately I think I agree with Chris's position. I think the days are past when we could commit to the success of an overarching Uberthing, be it a macroframework, platform, or app server. Rather than commit your reserves in a desperate attempt to win the battle, you withdraw to avoid losing your whole army. That notwithstanding, if Zope is still the goal, I endorse Martijn's proposal. Like Gary said, it's admirable that he's taking a shot at this and we should bite our tongues on quibbling. In the past we've seen things like let's unify Zope by merging the Zope2 and Zope3 mailing lists get shot down by a couple of loud no votes. Loud no's have grown paralyzing. If Martijn's proposal gets traction, then perhaps we have a way around them. --Paul ___ 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] the Zope Framework project
On 3/3/09 9:37 AM, Kent Tenney wrote: I'll chime in as a newbie. It seems many of the comments preferring ad-hoc to structure come from we know what we are doing, we can take care of ourselves I think Zope has the goal of attracting new users, and the proposal has potential to make Zope more inviting to the uninitiated. Zope is very diffuse, making it a challenge to grasp. I know I would benefit from any initiative which sought to provide an overview role. I'm not sure that's a goal of this proposal. The word Zope will continue to have its previous series of semi-competing meanings. The word will now also be attached to Framework, which will be the emphasis. As I read it, regarding the diffusion, asking the stakeholders in the existing meanings of the word to yield is not part of the proposal. (Thankfully, as that is hopeless.) The focus, though, will be on greatest-common-factor of the shared meaning. Not a solution to diffusion, but an improvement. --Paul ___ 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] the Zope Framework project
On 3/3/09 2:42 PM, Chris McDonough wrote: Martijn Faassen wrote: And you think it's all due to the brand... Yes! Someone who *wants* to use basic ZCML directives but doesn't want zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and pytz can *already* use repoze.zcml; the only thing they don't get here is the brand. If we change the word brand to megaframework, things might become clearer. Grok makes framework decisions based on getting value from the Zope 3 platform. So what if our configuration language sucks in zope.location and pytz, we needed it anyway in our megaframework! This view likely represents the (indeterminately sized) population of Zope insiders. Repoze doesn't have fidelity to the Zope 3 megaframework as its goal. I asked for a configuration parser and you sucked in a security model, WTF!! As such, Repoze probably wants something more like Zope-the-library than Zope-the-megaframework. This view likely represents the (indeterminately sized) population of Zope skeptics. Which group wins when there's a tie in the Zope Framework? It will be interesting to see. I think there's also a point about the brand related to how diluted the word Zope has become, but that is a second point to the megaframework/platform discussion. --Paul ___ 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: sad news about Joachim Schmitz
Martijn Faassen wrote: Hi there, Joachim Schmitz, long-standing member of the Zope community, died last weekend. Please see the following: http://faassen.n--tree.net/blog/view/weblog/2008/05/14/0 That was a wonderfully written memoriam, Martijn, thanks for writing it. A number of things you wrote brought back very vivid memories of Joachim. He's one of the originals and we were lucky to have him as part of our community. --Paul ___ 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] Two visions?
Stefane Fermigier wrote: Geoff Davis wrote: I think that the idea of giving Zed its own, distinct identity is great.. I think it is stupid. We (Zope Corp + the Zope Community) have spent 8 years building the Zope brand, and you want to restart from scratch ? Hehe, poor Geoff. :) In the past, the Zope community hasn't made it a *strategic* goal to play nice with other Python projects. In the past, the Zope community hasn't made it a goal to be a sea of autonomous components. Its goal has been: top-to-bottom app server. We now have (I think!) said those goals are now in scope. Those goals are currently being met using the same name as the assembly. Trying to achieve the goals of the components, using the same word as the assembly, might not be the best way to achieve those goals. The comments I got on my pro-Zope weblog post showed that, if we *do* care about these new goals, we should consider whether the name is a barrier *for the components*. Alternatively, we could say: The components should only be used in the Zope application server. Perhaps that's the goal. I think Geoff's core point could be met by keeping the word Zope for the app server. I think Geoff's deeper point was to rethink the word used for the CA, which actually doesn't want to be thought of us an app server. --Paul ___ 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] Two visions?
Geoff Davis wrote: On Thu, 02 Mar 2006 10:38:03 -0500, Jim Fulton wrote: I think that the idea of giving Zed its own, distinct identity is great. Zope 3 is a _huge_ overhaul and it needs to be obvious to the world that it is dramatically better than crufty old Zope 2. Zope 3 then becomes the Zed application server; Zope 2 is getting Zed retrofits via Five, and the two will eventually converge into Zope 5 (or Zope 2.27 or whatever). Ooops. OK I guess I was clear as mud. :) My idea for Z, pronounced zed or whatever the naming gods decide is that it was *not* an app server. It is an un-app-server. :) A collection of technologies that are useful by themselves, to support an app server and useful to build non-app-server applications, web or otherwise. No, I think I understood you. I was being sloppy in my use of language. I should have said something more like Zope 3 then becomes an application server built around the Zed library. Good clarification. I think that Z3 is better than Z2 in a lot of ways. I also think that Z2 is more mature and complete. I really want us to combine those efforts. I think we've achieved enough and learned enough with Zope 3 that we can now bring that to bear and make Zope 2 better, refactoring the cruft away and applying the lessons we've learned with Zope 3. (Note that Zope 3 is not crust free.) I don't really care what this thing ends up being called, except that it *must* be called Zope. Yes, I agree. Zope is the app server. I think that is consistent with the past use of the brand. Yep. This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's advice and release our technology in bite-sized chunks. I'm hopeful that the packaging efforts underway will lead to more of that. Yes, and the use of the new name Z or Zed is a way to emphasize that the Zed library is NOT a big, monolithic app server; rather, it's something new and cool. I think this brings up an interesting paradox in the discussion. We want Zope to continue being the name of an app server. But we also want the CA to be perceived as usable outside of an app server. Outside of Zope, even. Thus, we are using the same name used to convey: It *is* an app server! It's *not* an app server! I think this might be a contradiction and might be worth discussing. People have it set in their brain that Zope is a monolithic web application server. Hard to dispel that meme. --Paul ___ 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: [Z3lab] Nuxeo supports Zope Corp announces
On Jun 17, 2005, at 1:49 PM, Jean-Marc Orliaguet wrote: However, most members do not write code during their free time, do they? What happens when the members write code under working hours, their respective employers must well have something to say about it? The PF actually did research on this and got legal help from Eben Moglen and the Software Freedom Law Center. Answer is: almost the same way as Apache does it and the FSF does it. The employer signs a contribution agreement *but* is not a voting member of the foundation. --Paul ___ 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: [Z3lab] Nuxeo supports Zope Corp announces
On Jun 17, 2005, at 1:52 PM, Stephan Richter wrote: On Friday 17 June 2005 07:16, Jean-Marc Orliaguet wrote: Then when I look at the members of the Plone foundation ( http://plone.org/foundation/about/board/list ) I only see companies, except that ZC is not represented. So even if every member gets a vote, how much does that vote count in the development process of Zope2, CMF and Zope3 ? Ugh, I hope I misread this. If the foundation or any other instituation ever influences the Zope 3 development process, I will not contribute any more. I rather have ZC-centric development platform and the freedom to choose what to do for a release (in agreement with the other Z3-core developers) than a vender-independent foundation with a foundation-driven development cycle. In the case of the Plone Foundation, the PF is specifically excluded from the development process of the community. Its mandate is limited to organizational issues. Other foundations approach things a bit differently. (I did quite a bit of research on this for the Plone Foundation.) Also, I agree with Andreas and Philipp that developers should be members, not companies. Otherwise, how could I, as an independent developer, have a say? BTW, this is also positive for companies, since they can have several developers being members. In the proposed scenario, my one-man shop would have a lot of power compared to larger companies, such as ZC, Nuxeo, etc. Correct. The essential ingredient, and hardest one for the different cultures of different communities, is to establish the definition of merit. Is it only code? If so, how much and what kind? If not, what else is valuable? Most of the successful communities have a (subjective) definition of merit, used to evaluate membership. --Paul ___ 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: [Z3lab] Nuxeo supports Zope Corp announces
On Jun 17, 2005, at 2:49 PM, Stefane Fermigier wrote: Paul Everitt wrote: Other foundations approach things a bit differently. (I did quite a bit of research on this for the Plone Foundation.) Eric has done some research recently on the different successful Open Source / Free Software foundations out there that have the mission to develop and promote great software. We're looking for a model that is just as acceptable for the single developers (who are a very key elements in the community, and provide some of the best work around - see Stefan or Philip for instance, but there are many others whitout whom Zope and specially Zope3 would not exist as we know them today) but also for the companies and organisations that depend on Zope for their business and are willing to commit ressources to the development of the software (this includes software development houses like Zope Corp, Infrae, Nuxeo and 10s of others, but also companies or universities or non-profit that depend on Zope for their ongoing operation - like Chalmers university or like the SD houses customers). :^) IMHO, vendor-neutral means, in this context, that the Foundation must take into account the interests of all the stakeholders (individual hackers, vendors, customers), and shouldn't be interpreted as vendor-free. The governance model should take that into account, and not limit itself to only individuals are members (of course, companies are represented by individuals, but what happens if the individual in question leaves a member company for another?). First, let's agree that this isn't pre-decided. That the community will get the governance model it wants. Agree? Second, can you find examples that support this? For example, here's what Apache says: http://apache.org/foundation/how-it-works.html#roles All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions. Here's what GNOME Foundation says: http://foundation.gnome.org/membership/ Membership eligibility is an individual determination: while contributions made in the course of employment will be considered, they will generally be ascribed to the individuals involved, rather than accruing to all employees of a contributing corporation. These are two very successful open source projects. However, there is nothing to suggest that our culture is the same as these others. What's most important is that the rules are defined by the community. Let's ensure that the bootstrapping group is representative. --Paul ___ 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: [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements
This is really interesting! A year ago I put Python + Zope on a USB key, just for fun. It would barely fit so I looked at zip techniques, and never could figure out how to get ZPTs etc. to load from a ZIP. How did you do that part? --Paul Dieter Maurer wrote: Dear Zope developers, we have used Zope+CMF+Archetypes in a new way -- not as a Web Application framework but as a framework for desktop applications that share a large part of their functionality with online applications (implemented with Zope+CMF+Archetypes). A major stumbling block has been Zope's incredibly high startup time. We observerd times in the order of a minute on computers with either slow CPU or slow IO. This may be acceptable for a Web server but is prohibitive for a desktop application -- especially as the predecessor application started within a few seconds. To overcome this obstacle, we tweaked Zope and fixed Python's import mechanism such that Zope now starts either out of a ZIP archive or as a frozen application. These measures had the following results. Startup times on a mid range computer (AMD Athon 1.4 GHz; 512 MB memory) with a standard IDE disk. Cold start Warm start (after computer startup)(most files in OS cache) File system13s5s ZIP archive 8s4s Frozen 5s3s In more details, we did: * implement a package for a new kind of urls pypackage: for package relative access to resources. The package monkey patches Python's open, os.listdir, os.stat to provide transparent access to pypackage: identified resources. It currently support package relative access for packages loaded from the file system, from a ZIP archive and from the executable itself (i.e. frozen packages). In the last case, the resources are in a separate ZIP archive. This package might be interesting for Python as a whole as it is not Zope specific. * implement a shared object importer to be used as a Python meta_path hook. This importer allows to load shared objects into the context of a parent package (such as e.g. ZODB.TimeStamp) although the shared object is not located inside the package's source (ZIP archive or executable). * fix about 70 occurrences in Zope code where package relative access was implemented by dirname(__file__) to consistenty use package_home. * modify about a dozen places in Zope+CMF to use pypackage: and cope with __path__ not being a list for frozen packages * fix a few products (Archetypes and friends, TextIndexNG2, PlacelessTranslationService, ...) to use package_home (rather than dirname(__file__)) and not to change the current working directory (which obviously would fail for destinationsbe in a ZIP archive or the executable). * implement lazy loading of ImageFiles to reduce the risk of recursive imports (and reduce startup time). * support lazy product initialization * support configuration from a pickle file (to avoid expensive parsing of the schema and configuration files). The pickle is used as a configuration cache. * fixed Python's import mechanism not to treat ZIP archives as a directory when the archive could not find a module. If you were *really* interested in these startup time improvements, I could provide patches which might be integrated in the Zope core for e.g. Zope 2.9. ___ 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: Editing using Firefox
Are you doing this as a XUL app, with an html/xul iframe inside each tab? --Paul Jeff Nielsen wrote: Sorry in advance if this issue has been covered a bzillion times already Im playing with editing my Zope site using Firefox as I can open Document and Method objects in tabbed windows and switch back and forth between them. However, the tab title, based on the page title, for each object is just Zope. Is there a way to get the object name to be used as the page title and hence the tab title? Ive searched about a bit for an answer and no joy so far. Jeff Nielsen UgoFast http://www.UgoFast.com [EMAIL PROTECTED] ___ 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 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, CMS, IDEs (was: The bleak Future of Zope?)
On Thu, 22 Apr 2004 11:15:58 +0100, Seb Bacon [EMAIL PROTECTED] wrote: Joachim Werner wrote: There are quite a few Zope-based CMS solutions out there, and most of them are better than their commercial counterparts in many respects. But if we had managed to start a joint CMS effort (other than CMF, which is a failure by design) two or three years ago things would look even better now. It would be great to start something like a Zope3 CMS interest group up, to pool all our CMS experience - start collecting requirements, etc. Seems like a mighty large task, though :-) I'd like to at least have a session on this topic at Europython. Heimo and I have proposed a panel with the CMS's for Zope, to discuss the future of content management in Zope. My goal is to have a session that is structured enough to actually make a constructive step forward, if only in understanding and agreement. Particularly regarding Zope3. The panelists would be the implementors of current CMSs for Zope. How bout you, Silva, CPS, and Plone? Any others? --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: RDF Musings and TinyTables
Good grief, how did I miss this!! Shane Hathaway wrote: I just read the RDF article published here: http://www.xml.com/pub/a/2003/02/12/rdflib.html Yes indeed, that is a very good article. I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. I think you are 100% correct, maybe 110%. :^) In the last two years I made several attempts at grokking Mozilla and RDF was always the wall I ran into that prevented further progress. In the last three months I slowly, surely, forced myself to study it. Write things down, take notes, rewrite them down, etc. The light bulb has definitely gone off for me now, and I see things exactly the way you describe it: 1) It's an abstraction. Once you start working with it, you realize what this means. You take a bunch of information and throw it into a bucket. You also throw in how the information relates to each other. 2) It's a database. You have a pretty formal way of asking questions and making sense of the stuff in the bucket. You also have a way to put things in the bucket, and also to rearrange the stuff in the bucket. 3) It's ad-hoc. You don't have to know everything beforehand like SQL. You also don't have to control the containment hierarchy like you do with XML. (Took me a LONG time to realize the significance of the latter point.) The ad-hoc part is, for me, the key. Relational theory provided the theoretical foundation for modern online transaction processing. But things like content management are a much different problem. (One analyst states that unstructured content is 80% of the information in a business.) RDF, in my view, is the equivalent of a set theory, a formal foundation, for content management. Without it, everyone has to build their own framework for stitching things together, for connecting the dots. Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. That's right. I've always been surprised when I threw some RDF/XML into Mozilla, then got a dump of the serialized results. What I put in doesn't look like what I get out. That's because there is an abstract model. The XML can look a couple of different ways, and you still have the same abstract model. It took me a while, but I learned how to take advantage of this. With Moztop, I'm taking a pretty loose, distributed approach to content managment. I collect RDF from a bunch of different servers, throw it all into one big graph, and use this to draw widgets on the screen. The ability to make an assertion into a completely different part of the tree is something you can't do in XML. This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product called I will do everything in the universe to help such a project. How is that? :^) I know what the practical benefits that RDF can mean for content management. And it isn't esoteric Semantic Gibberish. I'm unable, though, to map it on the server side. However, I'm having luck on the client side: http://www.zope-europe.org/Members/paul/tmp/moztop-pinstripe.png RDFBucket? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded Yes, this is very similar to the client side model in Mozilla. I'm doing things like: o Assembling a hierarchy o Making up new hierarchies where none existed before o Generating property sheets o Doing conditional display o Making rich connections between loosely-coupled objects, meaning, objects that didn't expect to be coupled o Allowing data from Zope 2 and Zope 3 sites to be collected, presented, and related in the same interface Mozilla's template model is interesting to at least investigate. What's interesting about it is the way you can follow relationships in the model to draw things on the screen: http://www.mozilla.org/docs/xul/xulnotes/template-primer.html In this very simple example: http://www.mozilla.org/docs/xul/xulnotes/template-bindings.html ...note the last two resources shown in friends.rdf. Instead of repeating information in every row, you get the equivalent of a join. Except the result of that join can produce another join. The template builder keeps following relationships. Also, you can join to something on another server. RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages I'm wondering if I'm thinking in line with RDF theory,
Re: [Zope-dev] Re: RDF Musings and TinyTables
On Friday, Feb 21, 2003, at 04:16 Europe/Paris, Craeg K Strong wrote: Paul Everitt wrote: On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote: - RDF is hard to read, but legibility by humans isn't its primary focus. It's more concerned with providing a way to declare any relationship about anything. Right. That's what the graph tool at the W3C online validator is for. :^) Just throw it some RDF and let it draw a picture for you. Fascinating discussion. Could you please share the URL of this validator you mentioned? http://www.w3.org/RDF/Validator/ I am assuming it is based on GraphViz/IsaViz technology? Or is it something totally new? Nope, it is indeed GraphVis underneath. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Plone/Metadata/FUD
On Thursday, Oct 3, 2002, at 03:54 Europe/Paris, James Johnson wrote: I've been around the Zope/Python scene for many years. One thing I see this group suffer I believe if from the groupthink mentality. Imho Alexander Limi 2 cents worth demonstrated Erik's point perfectly. applaud the effort made with plone. I believe it to be a spoon in which we can spoon feed newbies into the CMS side of the Zope way. Seem my post regarding Zopezen.org. Plone is slow. Zope with CMF is slow... Not as slow as plone, but the issue is with ZPT. There is no way around it Erik is right. Developer time being spent on speeding up plone in order to backport the improvements to Zope/CMF sounds... Well arse backwards. Plone has its place, but I suspect some doublespeak here, lets be realistic about it. The Plone people are a layer above CMF, which is a layer above Zope, which is a layer above Python, which is a layer above the C library, which is... Do the Plone people have responsibility for all the layers below them? Nope. If there was a bug in the Python compiler (and in the last six months, there was one), should Plone have to fix it? Should they also fix problems in the Linux virtual memory model if they find that too? Nope. I debated a long time ago about CMS being the core of Zope anyway, but lo and behold they pushed on with a CMF product. I see plone as being the same, a Two errors here: a. The Zope community, on the whole, doesn't want Zope narrowed exclusively to content management. b. The CMF isn't a product. It is a framework. It specifically intends to not be a product. product. Now my understanding is that with Zope3, they will roll a lot of the CMF functionality into Zope3 Hmm go figure? All that time wasted on maintaining 2 This isn't precise. The CMF machinery, the part not unique to content management, is going into Zope 3. The effort for content management in Zope 3 is being managed as a companion project: http://lists.zope.org/pipermail/zope3-dev/2002-September/002819.html I'll note that you are neither subscribed to the Zope 3 mailing list, nor have you commented on the email above. If you're not even participating, then you should be more circumspect when making assertions such as: products Zope/CMF has proven cumbersome at the least imho. Now just imagine if the community would have listened to the lone voice James-then/Erik-now where we ...this. How can we listen to you if you're not participating? But to your point: the Zope community does not want, IMO, Zope and CMF merged. Content management is a piece of the Zope pie, not the whole pie. would be today. We all know that the decision back then was based on commercial interest for ZC and others trying to market some industry catch phrase. I have no idea what you are claiming. In fact, the reverse is true: ZC is focused on content management, but ZC realized others want to do different things with Zope. Thus ZC didn't turn Zope into a CMS-exclusive thing. Doing the CMF outside of Zope allowed the CMF to make rapid progress in a focused area without making promises that Zope itself would have to live with permanently. This has worked perfectly. We all now know a lot more about the patterns of content management. We can now refine them, and refine Zope, with the work on Zope 3. Tell me, do you think KDE should be merged into X11? It is exactly the same analogy. You're also claiming that Erik is voicing your opinion. I don't believe Erik wants a one-size-fits-all CMS product that everyone must support, nor do I believe Erik wants Zope to be focused exclusively on content management. However, I don't pretend to speak for Erik, so he can correct me if I'm wrong. So I hear you Erik, you have these wonderful, bright people working on special interest projects, but not on the core issues that allow Zope to have that strong core that it needs to move it forward. People work on what they want to work on. Alex Limi knows CSS and doesn't want to learn how the ZPT compiler should be optimized in C. It is unfair that you demand that he learn how to program in C. It is also wrong. Zope has more people that know C than know CSS well. We are lucky that Alex is filling an unmet need in the world of Zope. With it being evident in how the Release early/Release often mantra has been Explain how this is thrown by the wayside. You can, every single day, make a checkout of any part of Zope. Sure there was a gap between 2.6 alpha and 2.6 beta. But that's a single datapoint. Name another datapoint to support your conclusion. thrown to the wayside, I'm left wondering what do I do next with my 2.5.1 site? Do I go the plone, 2.6, 2.7 or 3.0 route? Going the Plone route is orthogonal to choosing a Zope version. Not a single person in the world of Zope claims that 3.0 could even run a prototype system, much less
Re: [Zope-dev] Zopezen.org is slower! Should time be spent on Plone or ZPT speed?
On Thursday, Oct 3, 2002, at 07:14 Europe/Paris, Andy McKay wrote: I smell commecial interest here. I smell people trying to make that one killer project hoping to make it big, instead of centering around the one vehicle that will help make a bunch of projects big someday. I won't deny it. I believe I can sell Plone and I'm not sure I can sell Zope as easily. Its a simple fact that I have to sell what the clients want: if I spend all my time concetrating on Zope innards, I doubt I'll be able to pay the mortgage. In the last 3 months 75% of my clients have come to me for Plone, in one case I steered them to a solution in Zope because I felt it was a more appropriate solution. I agree with Andy. Zope is a tool. Things like Silva and Plone are products. The purpose of Zope is to allow people to build things like Silva or Plone, or things quite different (perhaps custom to their own needs) quickly. And frankly, tools don't sell themselves. People want to see glitz. You could argue that Zope should be the project/brand with the glitz. But you're now limiting people's choices, because you're turning Zope into a product rather than a tool. Back to the X11/KDE argument. Ever looked at an X11 server running w/out a window manager? That's Zope. But it's wrong to fix the problem by eliminating X11 and merging it with KDE, because then the Gnome (and windowmaker, and sawfish, and...) people would be unhappy. Layers provide choice. Sure, they also provide a bit of confusion, but this cost is far outweighed by the benefits. Especially in open source, where people participate because they want to participate, not because they have no other choice. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zopezen.org is slower! Should time be spent on Plone or ZPT speed?
On Thursday, Oct 3, 2002, at 10:51 Europe/Paris, James Johnson wrote: Please don't get me wrong, products like squishdot, CMFZen, and others have steered me towards Zope. They are fine examples of the things that make Zope appealing. But if you really think about what I'm saying you might understand my meaning. Zope--is to MTV and Plone -- is to VH1. Squishdot-- is to CMT. The funny part of your analogy: MTV is the creator and owner of VH1. Now why do you suppose they did that? :^) --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Interested in sprinting at EuroPython 2002?
First, as a friendly reminder for EuroPython 2002: ***Early registration is open !!!*** *** https://secure.zope.nl/europython/Registration *** Deadline is May 31. Now, on to the good stuff. The EuroPython 2002 conference, http://www.europython.org, is in Charleroi, Belgium. We are planning a sprint the Sunday, Monday, and Tuesday before the confernce, making this sprint cover June 23-25. The goal of this sprint is like most others: education and spreading the word. However, we would like this sprint to attract a group of people that are committed to participating in Zope 3 after the sprint. If your interest is simply in learning about Zope 3, there is a tutorial the first day of the conference that might be more appropriate. The requirements are simple: you need to know how to develop in Python. Even Zope experience isn't mandatory (though it is quite useful.) We hope to have two groups of sprinters, with 6 or 8 people in each group. This means 3 or 4 pairs. If you are interested in sprinting and want to participate in the ongoing development of Zope 3, please email me (Paul Everitt, [EMAIL PROTECTED]) to sign up. More (and updated information) is available at: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/EuroPython2002Sprint --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] how bad are per-request-write-transactions
ForkedStorage, I like it simply for the coolness of the name. :^) But it sparked a different kind of idea, leveraging a pattern that might emerge in Zope 3. Let's say we had a queue in Zope. We could asynchronously send changes into the queue. Later, based on some policy (e.g. idle time, clock ticks, etc.), those changes would be enacted/committed. Imagine the queue itself is in a different storage, likely non-versioned. Imagine that the queue is processed every N seconds. It takes all the work to do and performs it, but in a subtransaction. Thus you might send the queue ten increments to a counter, but only one will be committed to the main storage. To make programmers have to think less about the queue (send in the object reference, the method to use, and the parameters), you could make it look like a special form of subtransactions. That is, you say: tm.beginQueuingTransactions() self.incrementCounter() self.title='Simple change' self.body = upload_file tm.endQueueingTransactions() At the transaction level, all enclosed changes are queued for later commit. You don't have to think any differently than rather object state management. This pattern applies better when you have a lot of document cataloging to be done. A separate process can wake up, make a ZEO connection, and process the queue. I don't think that indexing documents *has* to be a transactional part of every document save. Under this cron-style approach, you also pay less of a conflict-error penalty, as you can increase the backoff period. There's no web browser on the other end, impatiently waiting for their flaming logo. :^) Ahh well, fun to talk about. Maybe this time next year we can repeat the conversation. :^) --Paul Shane Hathaway wrote: Jeremy Hylton wrote: CM == Chris McDonough [EMAIL PROTECTED] writes: Completely agreed. My disagreement is portraying the counter problem as impossible with the zodb. I think some people, as evidenced by some of the responses, are willing to live with the tradeoffs. Other people will find managing a log file on disk to be a more manageable solution. CM It would be best to make make a dual-mode undoing and nonundoing CM storage on a per-object basis. I'd really like to do this for ZODB4, but it seems hard to get it into FileStorage, without adding automatic incremental packing to FileStorage. Example: Object A is marked as save enough revisions to do a single undo. When a transaction updates A and makes older revisions unnecessary, there's no obvious way to remove them without doing a pack. We could write a garbage collector that removed unneeded things (as opposed to packing everything to a particular date), but it doesn't seem very useful if it needs to be run manually. One idea I've been floating in my head is the idea of a forked storage, where some objects are stored in an undoable storage and others are stored in a non-undoable storage. I could try to explain it in English but pseudocode is easier: class ForkedStorage: def __init__(self, undoable_storage, non_undoable_storage): self.undoable = undoable_storage self.non_undoable = non_undoable_storage def store(self, oid, data, serial): if not serial or serial == '\0' * 8: # For new objects, choose a storage. want_undo = self.wantUndoableStorage(data) if want_undo: storage = self.undoable else: storage = self.non_undoable else: # For existing objects, use the storage chosen previously. if self.undoable.load(oid): storage = self.undoable else: storage = self.non_undoable storage.store(oid, data, serial) def load(self, oid): data, serial = self.undoable.load(oid) if not data: data, serial = self.non_undoable.load(oid) if not data: raise POSException, 'data not found' return data, serial def wantUndoableStorage(self, data): u = cpickle.Unpickler() module, name = u.loads(data) class_ = getattr(__import__(module), name) if getattr(class_, '_p_undoable', 1): return 1 else: return 0 Only a simple idea. :-) Also, how would you specifiy the object's packing policy? I'm thinking an _p_revision_control attribute or something like that. If the attribute exists on an object, it sets a particular policy for that object. Do individual transactions need to play in this game, too? I'm imagining a use case where an object is marked as no revisions but you want to be able to undo a particular transaction. I'm not sure if that means : - you can undo the transaction, but the no revisions object keeps its current state. - you can undo the
Re: [Zope-dev] Re: [Zope3-dev] Are there Graphic Designers?
I think this conversation is trending in the wrong direction. Zope 3 needs to make it possible to build YABB, interfaces which support all browsers while still looking slick, etc. However, it is important to note: Zope 3 is *not* a product. It is used to build products. The core ZMI is needed to the extent that it helps build or administer products. Thus, Zope 3 is not like YABB. Of course, Zope 3 can ship with one or more sexy sample applications, like YABB. But if we blur the line for Zope 3's ZMI, we'll be right back into the core problem of Zope 2's ZMI: audience confusion. One of the first questions to ask when building an interface is What is the audience? Giving a very focused, tough response can greatly boost effectiveness. With all this in mind, I think we can require developers to use standards-compliant browsers, and allow/facilitate them to build backwards-compatible interfaces. --Paul William Trenker wrote: At 12:47 AM 4/5/02 -0500, you wrote: I've spent more time making the Python docs work in NS4 than making them look good in more modern browsers This is sad but true. I still have Netscape 4 here for testing as well. (I run into the same problem with other web technologies, like Macromedia Flash. Yes, probably 97% of browsers do have a Flash player installed, but what version? Many are still at Version 3.) Those Download FREE upgrade buttons may as well be invisible. I don't think we should let Zope3 look ugly on old browsers, but isn't it acceptable for it to look more modest? With careful use of CSS, it is possible to let the older browsers fail gracefully. And it is amazing what can be done with very little CSS and lots of images. The page at, http://www.yabb.info/community/, has 2 styles, no Javascript, and looks very respectable. But look at all the GIF's. If the web-centric, software-tools development community feels strongly about perpetuating old browsers (and old web standards) then isn't it about time for that community to provide tools to hide the details? When will Python, and for sure Zope, have built-in browser detection and formatting support driven by some sort of meta format that let's us application developers get on with developing applications? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug days
I don't think we can do the geographic coverage without making it too painful. We should split bug days in half; a few hours in the morning and a few hours in the afternoon. --Paul Brian Lloyd wrote: Hi all - In an effort to better keep up with the collector, I'd like to throw out the idea of doing periodic bug days (a la the mozilla bug days), where Zope geeks and committers would get together on IRC and spend a few hours knocking out issues. I've drafted a preliminary bug day manifesto that describes how it would work in a little more detail: http://dev.zope.org/CVS/BugDays I'd like to hear what people think, as well as work out a few logistics: - Given the wide geographic area that committers (and patch submitters) cover, what is a good time of day for a bug day to start / end (where start and end are always going to be fuzzy, of course). - Would it be better for bugdays to be ad-hoc, or should we try to set up regularly-scheduled bugdays at some reasonable interval? If the latter, we need to come up with a day / time that is agreeable to as many of the committers as possible. Thoughts? -Brian ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope on Linux and Database as MS-SQL Server on WinNT
Take a look at: http://www.zope.org/Members/haqa/XMLKit/news-1.1.1 Adrian made an interface to ODBC Socket Server. --Paul Peeyush Garg wrote: Hi, What's the current best solution to utilize the combination of Zope on Linux and Database as MS-SQL Server running on WinNT. I don't find much information searching the Zope web site. Can somebody point me to some link? Thanks, Peeyush. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BUG] Python 2.1.2 Zope 2.4.1
Leonardo Rochael Almeida wrote: I'm really disappointed with ZC for putting out a new release of Zope instead of a fixed version of the release most everyone is currently using. 2.4.4 is ready, but there's a problem with the Windows build. I suppose we could just put the others up there w/out the Windows build, but then we'd wind up with 20 emails to reply to and explain over and over. All in all, only a few days separate the two releases, and obviously CVS people have been able to get at changes all along. Thus, I don't think this is an extreme case. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FYI: Sprint schedule online
Whew, at long last, I've posted a Sprint Schedule at: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SprintSchedule Boy, that URL is too long. I edited the dev.zope.org homepage to add links to the Zope3 page and the sprint schedule. This page also answers the question, What is a sprint? --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Q: Anyone want to sprint in Fredericksburg next week?
Howdy. This is a last-second email aimed at Washington-area Zope developers that might want to do a Zope3 extreme programming sprint with Jim next week, here in Fredericksburg. The dates are any two of Dec 26/27/28. Good knowledge of Python and Zope development required. Please reply to me today if you might be interested, and sorry for the last-minute notice. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: My thoughts on the development process
I've taken a while to respond on this, because I wanted to talk it over with folks here, to think about the specifics of what different ideas would mean, etc. In summary, your last paragraph says: So let's trade in some risks to the Zope core development (rash action and messed up stuff happening once every while), in exchange for a lot more active contributors. We agree, and it's my job to get us there. Here's the next level of specificity: 1) Lighter weight process. Brian and I have talked about it, and we agree that we should investigate ways to lower the bar on ceremony, *without* abandoning organization. However, we both feel that, as you noted, the ultimate issues lie elsewhere. Thus... 2) Improve the tools. There's merit to the argument that the state of the fishbowl isn't very discoverable nor usable. Folks on zope-web know that we're proposing work that we'll do. Also, we are open to work that others will do. 3) Delegate leadership. This is, IMO, the most important thing. We need more people in the core, leading important areas and making decisions. For ZC, this really means that we have to trust the trustworthy and accept the paragraph of yours I quoted above. 4) Find the leadership. We can't sit passively by and say, We opened CVS and nobody's done anything. Somebody has to work specifically and repeatedly to bring people in, make sure they know what to do, and perhaps even prod them occassionally to get working. This takes publicity, promotion, cajoling, communications, and all kinds of other things to get the momentum going. I've signed up for the last part. In general, I'm sure everyone is pretty talked out on this subject and ready to see some action and results to go with all the voluminous emails. Me too. So let this general state of the problem discussion rest for a while, and let's work on some of the good ideas already discussed. --Paul Martijn Faassen wrote: Hi there, I've read parts of the open letter threads just now. There's a lot of talk about how if only we have better tools the whole process will go better and Zope will get more contributors. That's a typical hacker response, and I do this myself as well. Throwing more technology at a problem doesn't always make a problem go away. And though technological solutions to social problems are nice if you can have them, and we should look for them, they don't always work. I'm not convinced more technology will make the dead fish problem go away. I think the contributing process is in fact too heavyweight. It should be easier for people to get in drastic changes to Zope. The only way for people to take more responsibility if they can actually have it. Only a few people will take it, but that's more than what is possible now, with possibly the single exception of my taking responsibility for ParsedXML. And until recently I was still in the position of doubting whether I really had it formally, not just de-facto. I kept asking for approval and guidelines from the official maintainers, but they were too busy (no blame to them), so I went on anyway and did a release eventually. I dread having to go through the fishbowl to add in my 'node path' implementation to ParsedXML. I've done the design work, I've implemented most of it, and I feel I'd have mostly wasted time writing a fishbowl proposal. I hadn't even explored the problem enough to be able to do that. I needed to prototype it to understand it. I've discussed some issues with people locally and and on the Zope-XML mailing list. And I'll probably release a version in a few days. Perhaps adding Formulator to the Zope core would be nice eventually. But going through the fishbowl bureaucracy would take forever. I only have so much time to spend on it, and I'd rather spend time improving the product itself. And now look at how the Zope core is actually being developed. Sure, there's lots of stuff in the fishbowl about what the Zope future should be like. Plenty of stuff, though some stuff is rather hard to find. But I have a lot of praise for what the Zope Corp people have accomplished it it; it's a lot better than having no such thing at all, even if it's only used as a notification service in part. The main thinking about the directions of Zope is not done in the fishbowl or on the lists, it's in the minds of the talented people at Zope Corp and in the brainstorm sessions they hold together. That's the natural way people work. I work that way too. Such a process can occur on mailing lists as well, but it's very hard to break into it. I've tried several times. I'll keep trying as I'm convinced it's possible, but it takes a lot of persistence. Time will tell. On the Zope-XML list I just post regular updates about my thinking to encourage discussion, and sometimes that works. So what am I trying to get at with this mail? One thing is that the process is too heavy-weight right
Re: [Zope-dev] Re: core i18n support
Lennart Regebro wrote: Well, all the i18n developers will have a meeting early January in Europe with Jim Fulton in a 2-day brainstorming session. Excellent! When and where? Yeh, cat's almost out of the bag on this one. Here's the plan. Note that all of this is tentative! As you may have read, we have been doing some Zope3 xp sprints lately. We're pleased with the results. In fact, we'd like to start a pattern of opening up the sprints to outsiders. We'd like to invite folks to Fburg for a sprint. Though you'll pay your own freight, we'll supply a spacious cubicle. :^) If you're interested, contact me. Second, Jim is hoping to go to Europe first or second week of January to do two sprints. The first is with a small (3 plus Jim) group to resolve the internationalization bottleneck and get Zope3 to do i18n and l10n. This first group will then help Jim do a larger (maybe 8) sprint the subsequent two days for other people in Europe. We haven't yet arranged for facilities. Third, we'd like to host an open house on the Thur and Fri after IPC10. Besides an open house, we'd like to have perhaps a massive sprint. Just to point out the obvious...this is a sign that we're listening on this discussion and trying to lessen the difference between ZC and the community. With Zope3 we have a chance for key community people to shepherd important pieces of the architecture. These pieces can include XML, i18n, cataloging, package management, workflow, etc. At the same time, these sprints provide a working session with face-to-face communications. It's a high-bandwidth way to make sure Zope3 does what the community wants. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Open Letters and Zope 3
Matt Behrens wrote: Shane Hathaway wrote: Again, this is all quite exciting and I hope you can join the action. I hope to. Who's in charge of packaging and installation? I see an opportunity to do it right this time, I hope I'm not too late to the party. I think this is an excellent area to bring in community members and let them have some ownership. There are a number of interesting initiatives out there -- in no particular order, Andy McKay, Andrew Milton, Adrian Hungate, Kapil Thangavelu, and Amos Latteier. We're interested in bringing more people into the core and giving them room to make decisions and have influence. It's an important lesson from the discussions over the last few days -- we don't scale that well and we need more leadership in the core. Thus, I'm looking for a couple of people willing to shepherd areas such as packaging and make a serious commitment for a fair duration. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Open Letter to zope-dev
Clearly this is a situation that has broken down. I'll suggest a resolution in a private note to you in a sec. --Paul Toby Dickenson wrote: On Sat, 1 Dec 2001 08:50:14 -0500, Andreas Jung [EMAIL PROTECTED] wrote: Also I had expect some input of the community regarding at unicode support inside Zope. But there has been no feedback. It looks like no one needs unicode support in Zope ?! :-) I see the smiley, but Im still not sure whether you are joking. Ive had stable, mature unicode support available as patches since Zope version 2.1. Im sure Andreas is familiar with them, we have discussed some details on more than one occasion. Ive expressed to DC several times that I am keen to get these patches into the zope core, and at Brian's request documented the changes in two fishbowl proposals (even that request seemed cheeky at the time; my patches were stable long before the fishbowl process ;-). He said he was keen to get something into version 2.3, then version 2.4, but so far nothing. The opening of the CVS is a good starting point but I would like to see more people contributing. So far it really does appear that nothing will happen about this particular issue until it is needed by a zope.com consulting project. If there is anything more that I can do then somebody please tell me what. Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Fishbowl?
Joachim Werner wrote: I think that there ARE problems that can not be solved on a mailing list or in the fishbowl. One of them is doing a good general design (which we MIGHT need for some of the Zope 3.0 issues). I followed all the stuff about the CMF and formerly PTK and knew that it was heading to a direction I didn't want, but at the same time I felt that it would not help if I just contributed to the mailing list. Maybe this was a personal problem of mine, but I don't think so. I don't think so either. I think your paragraph above does a wonderful job of concisely summarizing the challenge. First, there shouldn't be Annointed Tools. We should strive to have good tools, and we should strive to use good tools, but the real goal is communication. If the current approach isn't hacking it, we need something else -- which could mean we learn from successful patterns in other projects. Second, when communication reveals an issue -- what happens? Let's say that every single person in the world of Zope agreed that the CMF was going in a wrong direction (just for the sake of argument, as the CMF has people that like it as well as dislike it). Would anything actually happen if consensus was reached, and who would be the ones to convert conclusion into code? Third, as Brian pointed out and you conclude with in the paragraph, frustrated people tune out. This causes the other side of the communication to get frustrated and stop communicating. Then things break down. It's important to recognize this is happening, put aside the frustration, and address the problems. IMHO, there are two possible approaches to problems like that (major design issues I mean): a) dictatorship, if the dictator is really good in his job (e.g. Jim Fulton has done a great job with regard to the design of the ZODB ) b) meeting in real live (or at least in real time) Some of the core architecture of the KDE KParts component model was developed on the KDE 2 conference AFAIK. I think we might have to do sessions like that at the upcoming Zope/Python conferences ... That's a very good point. It's even a good point inside ZC. Getting ten people in a room for an extreme programming session has done wonders for our ideas on Zope3. Anybody want to fly to Virginia? :^) Yesterday morning I started hanging out on the #zope IRC channel. Already it has been illuminating. It also creates an atmosphere of understanding. I need to do this more often. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: core i18n support (was [Zope-dev] Open Letter to zope-dev)
As both Robert and Joachim (in another message) have noted, core i18n support is blocked by a single issue: there are two different approaches and insufficient consensus about resolving them. The first criteria that I have is whether someone is willing to become a CVS contributor and shepherd i18n in a responsible fashion, as Martijn Faassen has done with XML. In this sense we suffer from an embarassment of riches: both Localizer and ZBabel have people willing to step up and provide leadership. Unfortunately there isn't someone with sufficient authority on the subject to annoint one as more right than the other. And an arbitrary decision by ZC is sure to leave hard feelings. Unfortunately this needs to get cleared up soon, so that an i18n team can start influencing the component architecture. I suggest that Stefane and Juan David (Localizer/Nuxeo) and Stephan, Andrew, and Joachim (ZBabel/iuveno) have a little chat and make a recommendation for a small next step. --Paul Robert Rottermann wrote: Andreas, sorry if I have not reacted to a questions for assistance in the realm of i18n. I must have missed them. I rarely go to EuroZope since this site seems badly maintained. However I really would like to help with the internationalization of Zope since most of what we do here a my company must be multilingual. I do have considerable experience making programs translatable and I did a multilanguage CMF (with which I never was really happy) Some 6 Months ago I started to collect what is there regarding i18n and Zope. I did get a sizable number of answers. However there where two rather unfortunate tendencies: - multiple, different and incompatible attempts from our side - missing involvement and therefore no shepherding from ZC's side If, as Paul assures, the second point is about to be rectified it might be now the time to do a second such compilation and then start doing it. Robert - Original Message - From: Andreas Jung [EMAIL PROTECTED] To: Joachim Werner [EMAIL PROTECTED]; Paul Everitt [EMAIL PROTECTED]; Robert Rottermann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 01, 2001 2:50 PM Subject: Re: [Zope-dev] Open Letter to zope-dev - Original Message - From: Joachim Werner [EMAIL PROTECTED] To: Paul Everitt [EMAIL PROTECTED]; Robert Rottermann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 01, 2001 08:22 Subject: Re: [Zope-dev] Open Letter to zope-dev The second is pretty exciting as well. I saw a presentation in Paris by Juan David Palomar, of Localizer fame. (The presentation is now up at http://estce.act.uji.es:9673/localizer). The presentation impressed me on the need to get someone into the core of Zope that knows all these details, but also convinced me that the Zope3 effort needs to anticipate the needs of i18n and l10n. ZBabel and Localizer are good starts, but as jdavid says, both should be thought of as non-core projects that start influencing the core step-by-step. Hi! I fully agree that ZBabel and Localizer don't have to be core projects right now. But the core must be made fit for i18n to make sure that we don't have to patch things like the user folder implementation or the Help! button in the code. In Zopw 2.5, there still seem to be hot spots to fix with regard to i18n. Of course there are hot spots. I have asked multiple times for help on the mailing lists and the Eurozope site to identify such related hot spots. Also I had expect some input of the community regarding at unicode support inside Zope. But there has been no feedback. It looks like no one needs unicode support in Zope ?! :-) Anyway, as a first step Zope 2.5 provides full unicode support for the ZCatalog. I would like to see some volunteers that could help to set up a list of requirements (the list is almost there on the Eurozope site I think) and possible solutions that could be integrated into the Zope core. Referring to the open letter to zope-dev I could also charge the community for zero feedback. But this is not the place and time for flamewars. Instead we should bundle the power of ZC and the community. The opening of the CVS is a good starting point but I would like to see more people contributing. Cheers, Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Another open letter. :-)
Danny William Adair wrote: [snip] Have you seen this interview? http://www.zopera.org/site/Members/odeckmyn/iv_paul_2001 (recently announced on this list) Quote: Regarding CMF, we expect it to disappear in its current form, ... Introduced to us as the Portal Toolkit, later labeled as probably evolving into a commercial product (couldn't find it in the archives when I tried a minute ago, but I know I wasn't dreaming when I read it), then renamed to Content Management Framework and the out-of-the-box solution for site developers that need membership, skinning, an easy content management interface, and pluggable add-ons, Paul Everitt now calls it a big prototype for the new architecture. Although I think that this is not how it all started, not even how it meant to be less than a year ago, you see that your concerns are no longer something to worry about. The good things will be taken to the Zope core, the rest will remain interesting only for people who actually implement. Yikes! I need to get a clarification back to Olivier regarding my point on all this. First, the PTK/CMF evolved separately from Zope, which made it move pretty quickly. All along with thought in terms of the PTK/CMF trying out things that the more conservative Zope development wasn't going after. As we started thinking about Zope3 and a component architecture, we took a look at some of the ideas in the CMF and felt they were a valid approach. As such, the CMF could be thought of as a shipping prototype for ideas that will make it into Zope3. It's true that much of the CMF code should disappear if Zope3 does its job. Perhaps around 50% of the Python code, for instance. The remainder is in areas that we had mixed success on anyway -- namely, the CMFDemo portal doesn't really try to be an out-of-the-box finished product. Most of us would be thrilled to see a different killer app develop that took the place of this in Zope3. Certainly existing CMF users shouldn't be worried. For instance, we're planning two important customer engagements that are _just_ starting which will be CMF based. We want to work with people doing projects similar to the CMF and get some common ideas/machinery into the component architecture. Regarding the PTK possibly becoming a commercial product...well, some evolutionary paths are dead ends. :^) --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Open Letter to zope-dev
Agreed completely on both of those points. There's double good news on both: 1) Someone plans to do something about it. 2) Both are with community involvement. On documentation, someone in the community has committed to taking over the Documentation page on zope.org and finally organizing the myriad of useful, but unlocatable, doc resources out there. The second is pretty exciting as well. I saw a presentation in Paris by Juan David Palomar, of Localizer fame. (The presentation is now up at http://estce.act.uji.es:9673/localizer). The presentation impressed me on the need to get someone into the core of Zope that knows all these details, but also convinced me that the Zope3 effort needs to anticipate the needs of i18n and l10n. I spoke with the guys here doing the extreme programming session on Zope3, and they agreed. To say it again: 1) I think the world of Zope needs to grow 10x in the next year. 2) ZC can't do it, and much of the action in Zope is non-U.S., particularly Europe. 3) Thus, Zope needs a strong, competitive internationalization story. ZBabel and Localizer are good starts, but as jdavid says, both should be thought of as non-core projects that start influencing the core step-by-step. --Paul Robert Rottermann wrote: Friends, first thing I want is to express my huge gratitude to have something like Zope and its community. I have read all the all the mail that has been stirred by that open letter. I agree very much and I am willing to contribute as much as I can that zope should grow 10x. I found two things missing in the discussion so far that are crucial to attain this goal: - documentation To start using Zope doing something more than trivial is an incredibly frustrating thing. Hunting for the right piece of documentation is very very hard. The community is very helpful I agree readily. However asking it should be the last resort and being forced to use it as an important part of the developement effort is very cumbersome and time consuming. And does not really take the frustration out of the process. Bruce Eckels postings to this list show that even a developer of his statue is prone to the same effect. I am a seasoned programmer that started to deal with Zope exactly one year ago. It is only now that I learn where to look for what piece of information and to decide which one is relevant and which one is not. - translation support Internationalisation is crucial. English in the user interface is just not tolerated in a non English speaking part of the world. It is 10 years ago something like that would have been acceptable. I am from Switzerland where we pride ourselves to be multilingual (6 Million inhabitants 4 major languages, English being the fifth). However nobody would think of having anything like English on a public website. There are a number of efforts towards translation support. However to have any of them to succeed it needs the support of ZC which just does not exist. Now I have to hurry getting breakfast (or I get into troubles) Robert ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Fishbowl?
Chris Withers wrote: Paul Everitt wrote: Moral: there's a difference between correct and right. While we might have good reasons for inattention, it will surely lead to an unsatisfying conclusion. Thus, ZC needs to be smaller part of a larger Zope, IMO, and do this by spending more time helping the community take over parts of Zope and the Zope world. Well, this is a purpose, which is good. I'd say sorting out the Fishbowl would be a good action to start with. You're going to love the irony on this, but there's a proposal in the fishbowl on this: http://dev.zope.org/Wikis/DevSite/Proposals/FishbowlManageability ...and of course, nobody knows the proposal is there. Now, I see options for this: 1. We can build something better. I can list requirements but that's not relevent here. However, this will take serious effort (it's a hard problem...) and as we know from bitter experience, things that need serious effort either don't happen, take far too long to happen or happen badly ;-) Yep. I'm in favor of some very small, very incremental steps. 2. We could by a tool that does this kind of thing. Where would we get such a beast from? how much would it cost/ who would fit the bill? ...and what would be the transition costs? 3. We could use another open source tool. Bugzilla springs to mind. Yes, it's not Zope, or even python, but it does work, certainly better than anything we, as a community, have right now or could build in the time it would take to install and set up. Hmm, I don't really see Bugzilla and the Fishbowl overlapping. Perhaps with the Collector, though. However, I don't think the real issues involved are related to choice of tool. It's been mentioning that ZC doesn't pay attention, so proposals go in and nothing happens. Bugzilla won't fix that problem. I'll add that the community doesn't always pay good enough attention. Sure, people will say when will we have versioning or when will we have web services. We go off, make a proposal, and email zope-dev. No feedback -- I take that back, each has received one response, whether by wiki comment, mailing list response, or private response. This isn't a good track record. Brian produced 35 pages worth of almost-flawless docs on web services to go with his code. But no comments. And he's doing this on his own time. So let's remember that this is a two-way street. IMO, Bugzilla won't fix these kinds of problems. I think the first step is to refine what we have while finding better ways to work together. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: SV: [Zope-dev] Fishbowl?
Casey Duncan wrote: I propose (as I just did on zope-web) that ZC do one more little thing for us. Open the web infrastructure up to a few of us. I would be willing to spend a few nights hashing out a more active fishbowl system if that's what's important. Lets take that first step though. Sold. Get a group of four or five people that are willing to commit up to ten hours a week for the next month. Gather together on zope-web and talk about what you plan to do. When rough consensus is reached, we'll give you logins on the test server. When consensus is reached there, we'll give you logins on zope.org, because at that point, you'll have convinced yourself and others that you're in it for the long haul. It's easy to start. Subscribe to the zope-web mailing list: http://lists.zope.org/mailman/listinfo/zope-web ...and start discussing what needs to be done. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope has been Hijacked! Save Zope!
Chris McDonough wrote: Those who know of these problems can write clean applications but these issues are kept strictly confidential. Isn't this dangerously close to a conspiracy theory? Yes, he's right -- we hid the information on this top-secret thing called the World Wide Web: http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution Muhahaha! --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: SV: [Zope-dev] Re: Fishbowl?
Magnus Heino wrote: Well, that checkin was done to the cvs 4 days ago. If you haven't read the one line at dev.zope.org about it being available in the cvs, or if you dont subscribe to the cvs mailinglist, how are you supposed to know that it exists? :-P Actually, he sent an email to zope-dev on 11/26. Version control went to zope-dev on 10/23. Between the two, one email of discussion. This is why I'm leery of thinking this is simply a tool issue. I think we'll need more creativity, hijacking notwithstanding. :^) --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: SV: [Zope-dev] Re: Fishbowl?
Magnus Heino wrote: This is just a guess, but I suspect that this is a sort of unfortunate cycle developing: people post proposals, get (understandably) dismayed at the response time and end up not spending much time there, either contributing or providing feedback. Well, lets move this discussion to a wiki and see how it goes... This is a tool issue. I'd like to propose this crazy tool called email. :^) Anybody that thinks they'd like to participate in the building of a better fishbowl (particularly if your name is Chris :^), trot on over to [EMAIL PROTECTED] Let's hash it out, perhaps starting with Ken's proposal. Let's then make a proposal back to zope-dev and see what people think. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Fishbowl?
Brian Lloyd wrote: [snip] When we first opened the fishbowl, it was with the certainty that we wouldn't get it right immediately. That's why we went with the intentially low-tech approach of a pile of Wikis. That first step actually worked pretty well for a while until we hit critical-Wiki-mass and there were suddenly too many proposals / projects to follow easily. So please don't think that we are somehow attached to the current fishbowl implementation as some sort of be-all-end-all. When we first put it in place, we were minimal with the fishbowl, applying Jim's second law of engineering (You can't solve a problem until you know the answer.) Now I think we a lot more about the answer: [snip] This bears repeating: the fishbowl was _never_ intended to be thought of as a tool. Rather, it should be thought of as an approach, methodology, or culture. You can rip out the Wiki and replace it with the Collector or Bugzilla, and you'd still have the fishbowl. Months ago we reached critical-Wiki-mass. However, we've now reached the point where some people are volunteering to do something about it. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Open Letter to zope-dev
Chris was just drinking a beer with us at Orbit's twenty minutes ago, and now he's responding to email on a Friday night. That's just sick. I don't think your boss fully appreciates you, number 27. :^) --Paul Chris McDonough wrote: The session management framework (formerly known as CoreSessionTracking, now it is in the core and just called Session) is another example, if my first look was right. The API seems to have changed a lot between the last CST and the final Session release that is part of 2.5 beta. O.k., there still seems to be some backwards-compatibility, but why can't those projects be more public? The tools are there (like CVS) ... Mea culpa. One of the problems is that that nothing gets by the BDFL here (Jim), and he required some of the changes. But I admit that I should have kept the fishbowl project more updated. I did update it (lamely), but not well enough. -= C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fw: [Exuserfolder-devel] Zope 2.5b1 release
Yikes, it was pointed out to me that I typed amk instead of akm. Though I knew it was Andrew Milton and not Andrew Kuchling, I mixed up the letters. (In fact, as I was typing it, I was thinking wow, that looks like Andrew Kuchling's monogram.) --Paul Paul Everitt wrote: Whew, that email (and the preceding one in the thread) is quite a whopper. In substance, amk raises some pretty serious issues that we need to come to grips with very quickly. I don't have enough information to respond right now, but trust that we'll get a good response back today. Neo-moderator note: if the discussion _does_ start over here, everyone is advised to leave the anger at the door. Problems like this can usually be solved pretty easily by direct communication and open minds. --Paul Dario Lopez-Kästen wrote: I thought this might be intresting for discussion on zope-dev as well... /dario - Original Message - From: Andrew Kenneth Milton [EMAIL PROTECTED] To: Andrew Kenneth Milton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 8:45 AM Subject: Re: [Exuserfolder-devel] Zope 2.5b1 release It has been pointed out that perhaps the dripping sarcasm drowned out the acutal points of the email, sorry I was particularly pissed off at how half-assed it all was. If you are writing a product that needs to create a user, you go look in User.py and find out what the API since that tends to be the only place the API is documented. If you look at how UserFolder is implemented; a) The change to manage_* seems to be completely arbitrary, since we already had _do* methods that meant you didn't have to call manage_users with fake submit buttons. So what is the point of having manage_ ? b) manage_* methods usually indicate web callable methods, which these clearly aren't (no docstring, no REQUEST parameter). In fact they don't return a status at all, so they seem to doubly useless. c) If it's an internal API for applications then the methods should probably be protected by being prefixed with an _ to indicate they're not for calling from the web or from within Documents/Templates. d) Even if you conformed to the API by calling e.g. manage_addUser() this seemed to be incorrect, since it didn't do things like encrypt the password. This meant you would have to either a) encrypt the password yourself (*very bad for XUF*), or b) call _addUser() which is not part of a defined API but looks like it should be (i.e. manage_addUser and _addUser seem to be reversed in functionality). ii) This is compounded by the fact you would have to query the UserFolder itself to find out if you should be encrypting passwords (what no UserFolder capability API?). e) s/_do/manage_/ doesn't constitute a new API. It's just the old one with the names changed. f) We've done a lot of work to make a flexible UF product that is I18Ned (well -able), and they still use the value of the submit button. I would have expected to see an alternative manage_users called from the ZMI that behaved much better, with manage_users calls raising warnings. g) Someone got paid to do it, and that just pisses me off, given the quality of the stuff we release for free (and I'm still looking for a job btw d8). We're not perfect, the 0.10.1 release shows that, but, at least we spent more than three minutes including thinking time on it, and I at least try not to change things just for the sake of it. Anyway. In case you were wondering what the previous email meant, there's the actual meaning d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| ___ Exuserfolder-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/exuserfolder-devel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope
Re: [Zope-dev] FYI: Zope version control project
We misfired on an Apache configuration and the Apache's weren't listening. It should be back. --Paul Chris Withers wrote: Brian Lloyd wrote: Hi all - We've started a new fishbowl project to address version control in Zope: http://dev.zope.org/Projects/Wikis/DevSite/Projects/ZopeVersionControl/ Is dev.zope.org down? Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] not Python 2.2a1 but Python 2.2b1
An important aspect to consider: in some cases, you simply need the ZEO storage server to have large file support. Thus, if you can get the ZSS running under Python 2.2, then you're set. This is considerably less ambitious than getting all of Zope (e.g. the catalog) migrated to a new Python version. Also, since Barry and Jeremy (or, as we say, Barremy) are now calling the shots on ZODB and ZEO, you can bug them about it. :^) They're likely to care a lot about keeping everything in track with Python 2.x. --Paul Martijn Faassen wrote: Hannu Krosing wrote: Andy McKay wrote: Is out and: Large file support is now enabled on Win32 and Win64 platforms, and automatically configured (at least on Linux and Solaris). Cool, that will mean there will be less worries about Zope users hitting the 2 gig limit. But will Zope 2.4.x run on 2.2 ? No guarantees, but I do know the PythonLabs crew and the Zope development crew try to keep things working with 2.2. That doesn't mean there won't be problems, but I don't suspect it'll be as tricky as the move from 1.5.2 to 2.1. The main thing is that the Zope C extensions keep working, but that seems to be watched fairly carefully. So, perhaps yes, perhaps no, but don't expect a long period of Zope trying to catch up with Python again. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPublisher/ZServer interaction (was Re: A modest proposal)
I don't know, there were quite a lot of ideas brought up. It started with a discussion of Twisted being swappable for Medusa. Since Itamar is a developer of Twisted, he should champion that effort (he knows a lot more Zope than any of us know Twisted). There was also a discussion about replacing Medusa by embedding in Apache. While Michel said we had thought about it, that's about the extent: we've thought about it. It isn't even scheduled for further thinking at this point. I think the best thing is for some people that care deeply about this to go off and prototype a little bit and see what's involved. --Paul Andy McKay wrote: So did we at least get a fishbowl out of it? Cheers. -- Andy McKay. - Original Message - From: Paul Everitt [EMAIL PROTECTED] To: Phillip J. Eby [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 12, 2001 7:23 AM Subject: Re: [Zope-dev] ZPublisher/ZServer interaction (was Re: A modest proposal) Wow, this is one hell of a thread. :^) FWIW, Grisha put a Bobo publisher in mod_python a couple of years ago. Thus, if you like ZPublisher-style processing, you can do it in Apache via mod_python. I outta contact him and see if he'd consider putting page templates in mod_python. Might be good for both page templates and mod_python. --Paul Phillip J. Eby wrote: At 08:00 AM 10/10/01 -0700, kapil thangavelu wrote: sadly the distinction between zpublisher and zserver is nowhere near as clean, i spent some time looking at it this morning trying to get my server of choice using zope. i thought it would be a mid morning hack, but the rabit hole follows the class heirarchy deeper and deeper:). all i have to show for my results is zope's output dumped to the server logs. its a start though... hopefully we get some new religion in the publisher, please... Hmm... Check out: http://cvs.eby-sarna.com/pylib/ZLite/ Specifically, the ZPlumbing module, for several examples of ZPublisher run loops using CGI and two different FastCGI modules. I don't know anything about Twisted, so I couldn't tell you how easy it'd be to use the ZLite framework for this. ZLite is the beginnings of my work on a Zope Lite distribution. It's sort of the Standalone ZODB distribution's evil twin - intended if you want to use almost anything *but* the ZODB and ZMI parts of Zope. That is, when you just want the app server without the IDE and application framework. Architecturally, it's intended for multi-process, single thread setups using Apache as a front-end, with FastCGI. This shouldn't be considered an announcement or a release, btw. The code in CVS is production-hardened by years of service (many millions of hits served), but is utterly without documentation, nor has everything I've written been checked into CVS yet. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTables and/or Catalog plugable brains?
Martijn Faassen wrote: I'm not entirely sure why the idea of ZTables went away so completely. Python tables in the ZODB combined with the catalog should make for an interesting system to play with. Though perhaps there are products out there that actually do this. Come to think of it, MetaPublisher (not to be confused with MetaKit) can use a ZODB backend, can't it? ZTables was a Zope1 product. We never updated it for Zope2. There's so much new machinery in Zope, particularly regarding indexing, that ZTables would really only serve as interesting requirements input. I certainly think that some kind of generic table tool in Zope would be useful. I'm sure that others could do a better job of it than ZTables did, in light of all that's happened in Zope and the CMF since then. In fact, Formulator probably has a role as well. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope on Windows/Mac OS X: BatteriesIncludedDistribution
Whew, what a proposal and what a good sign! As several have noted, there are quite a few proposals in the fishbowl that deal with different aspects of the problems. There's also a draft proposal that we had here in ZC that expands on the items. Finally, there appear to be a few pieces of software (yours, zctl, zopectl, etc.) that try to address aspects. I suggest that we all spend some time trying to revisit all the proposals, obsolete the ones that are covered elsewhere, and try to find the common ground. There is a dorman zope-packagers mailing list we could hijack for these purposes: http://lists.zope.org/pipermail/zope-packagers/ I think, with all the various efforts, it is time to agree on some standards regarding where configuration data lives and how it looks. --Paul Richard Jones wrote: I've just created the follwing fishbowl proposal: http://dev.zope.org/Wikis/DevSite/Proposals/BatteriesIncludedDistribution Please read and comment. Richard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [DISCUSS] Committer agreement not even handed and threadening
Dieter Maurer wrote: Paul Everitt writes: http://dev.zope.org/CVS/Contributor.pdf The Committer Agreement does not seem to be even handed: The committer transfers rights immediately and indefinitely to Zope Corporation (the contributions become a gift to Zope Corporation). This is an inaccurate representation. Transfer means you lose the rights and we gain the rights. Under joint ownership, both have rights. I think this point was abundantly clear, so I'm surprised to see you portray this as a gift. The agreement states explicitly that no rights are transfered to the committer. Because they never lost any rights. This is not a problem in itself. However My intention to contribute would be to strengthen the Open Source Movement. A statement that the supported code base (Zope) will remain open source and that committers will be able to use it (indefinitely) under terms comparable to the current ZPL would help to let the agreement to appear more balanced I don't think it's really feasible to 100% guarantee things in the future. Rather, the agreement states that current code, and any contribution, will be available under the ZPL. Nothing can be retracted. If someone comes along and gives us one trillion dollars to stop releasing our work as open source, two things would happen: 1) First, we'd take the money. :^) 2) Second, all the existing code has to remain available under the ZPL. We just wouldn't do _new_ things under a ZPL. This is part of the safety of joint ownership. If you don't like what we do in the future, you still have rights on your contribution. The Commitrer Agreement is quite threadening: A committer takes over a considerable risk (complete warranty and indemnification with respect to intellectual rights infringement). Yes. You can't make the risk disappear. Someone has to bear the risk. It makes zero sense for ZC to bear the risk of what goes on in someone else's brain. Even in the scenario of carelessness, a case will have to be made regarding what you knew and when you knew it. The risk is far higher than that of a (german) employee. German employment law recognizes that * all people make (sometimes) errors * coping with isolated errors is far easier for a larger community (the big employer) than a single individual. Therefore, it uses the term Fahrlässigkeit (carelessness). An employee has to take all care to not make errors during his work. If something bad happens due to slight carelessness (leicht fahrlässig), then this is a general risk which has to be taken by the employer. If serious carelessness (grob fahrlässig) was the cause, then the employee has to take the consequences for himself. We should have something similar for the committer agreement (not restricted to intellectual property rights!). Maybe something like an insurance for slight carelessness cases... Unfortunately we'd have to be the insurer. :^( Otherwise, commiting anything might easily ruin an individual. Instead, you'd prefer that it ruin ZC? Or are you asserting that somehow we could make it so that nobody would be held accountable? Especially with the strange US Patent Laws (where almost everything (such as presenting information in a popup window or integrating a Web Frontend with a baking oven) can be patented) and incredibly high damages amounts (5 billion for a smoker who got cancer) assigned in US courts. Unfortunately that's the jurisdiction in which we operate. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Multithread transaction problems in ZODB
First, just a friendly reminder that there is a zodb-dev mailing list. On this, check out Andrew Kuchling's page about ZEO development: http://www.amk.ca/zodb/zodb-zeo.html There's a section at the bottom with a brief discussion of ConflictError, what it means, and how to handle it. Zope automatically does the retry, but Python develops have to handle it themselves. Here's a link with some information about what's known as application level conflict resolution: http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution There's also some discussion at: http://www.zope.org/Documentation/Articles/ZODB2 Hope this helps... --Paul Cyril Elkaim wrote: Hi, We are testing ZODB directly from Python and have a multitread ConflictError problem. In short :-) if we open a connection in a first thread, then a second connection in a second thread and then commit the first one and then the second (the transactions are so interlaced)... Not only we have the ConflicError, even if obviously we do not modify or create the same objects. But in fact the last transaction doesn't even have its own objects saved. We are using ZODB from Zope 2.4. We have a similar problem using Berkeley Storage too (beta4). If the two threads are serialized eveything works fine (but that's no more multithreading no? ;-) So is it possible to access ZODB from a multithreaded application? Thanks in advance Cyril Elkaim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
Martijn Faassen wrote: http://dev.zope.org/CVS/Contributor.pdf This says 'you must indicate your agreement to the term below'; shouldn't it be 'terms'? Uhh...well...yes! I'll make the change. I'm waiting for news back from the lawyer about provisions for handling patches. I'll then post a new rev of the materials. Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control
I'd like to add some misinformation...errmm, comments. :^) On the version control side, you're quite right, we're still behind on it. There _are_ some ways to get there, if you try hard enough. But that's unacceptible. There are two things long term that need to be done: filesystem synchronization and version control. The former is a project to make it possible to represent and perhaps round-trip Zope data in a way friendly filesystem tools and patterns. This obviously includes SCM systems like ClearCase. We've had, at our Friday jam sessions, a couple of proposals on this. So far it's simply provoked rigorous discussion but not a lot of consensus, as balancing the competing goals is harder than it sounds. I was talking with Jim yesterday over lunch about this, and whether the new component model would put filesystem synchronization in its scope. The short answer is, not in the first cut. It will certainly make filesystem synchronization a lot easier, but we need to get it out the door and tackle filesystem syncing later. Regarding version control...this is something that has been burned into our skulls in recent RFPs that we've responded to. It's the number one thing we at ZC need to address to be more competitive in CMS bids. So far the goals and use cases of DeltaV seem to best describe what we're currently thinking: http://www.webdav.org/deltav/ http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm Note that this is for Zope itself to have a model for version control. Filesystem sync is the most obvious way to interface to a separate SCM system. However, _if_ Zope adopted a repository model, it's conceivable that Zope could have an implementation of the repository that used an external system. _Please_ understand that this is all hand-waving right now. But I'm on the hook to incept versioning, so it's informed hand-waving. :^) --Paul Jay, Dylan wrote: -Original Message- From: Kenichi Sato Sent: Monday, 24 September 2001 5:49 PM To: djay Subject: Barriers to Zope popularity: Part 2: source control Dear Mr. Jay, Dylan, I am Ken Sato, a manager of software development projects. I'm now taking a look at Zope as a tool to publish project related information internally. Zope looks nice but I found it has two potential problems. 1. WYSIWYG editing 2. Source control (by ClearCase) Then, I found that you pointed out exactly same things in the zope-dev mailing list. (http://lists.zope.org/pipermail/zope-dev/1999-September/001602.html) Because the post was two years ago, I wonder if you have already solved the above problems. It would be very helpful for me if you could give me some information on this issue, please. Hope you don't mind me CC'ing this to zope-dev. I still see both these issues as important and still see the lack of progress towards Zope working well in traditional development environments being a real outage. Plus others may have different opinions about the current state of affairs 1. I have not used Zope Page Templates but these are supposed to solve the wysiwyg problem. They are an alternative to DMTLDocuments. They allow for much better seperation of code and presentation. Get you graphics people to use webdav to edit the html with whatever editor they want and the coding people argment the html rather than rip it appart. http://www.zope.org/Documentation/Articles/ZPT1 Personally I like DTML and back then I did suggest a way DTML could used in a similar way to Page Templates (basically have a view mode of a DTML document that incorparates the rendered content as well as the DTML code such that when the page is edited and saved back, it will save all the changed parts back to the where they came from, i.e. the different DTMLMethods that made up the page). but like most of my ideas I din't have the ability or time to implement it. 2. Hasn't really been solved. There are sort of attempts that work now with CVS (I havn't tried it) http://www.zope.org/Members/sspickle/ZCVSMixin This but there are proposals that will better solve this problem, but no implementation on the way that I can see. The problem is really one of synchronization. You want two different representations that are both kept upto date. One for zope to use, one for all the reasons we have things under source control. You may or may not want control of when the synchronization occurs. Here are some related proposals http://www.zope.org//Wikis/DevSite/Proposals/SynchronizationMechanismZCVSMix in http://www.zope.org/Wikis/DevSite/Proposals/SynchronizationTab http://www.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst em I also see a lot of parallels with the work going on with ZODB replication. If you had replication between a normal ZODB and some filesystem source control ZODB then you would have the source control
Re: [Zope-dev] DISCUSS: Community checkins for CVS
OK, a response. Sorry for the delay. First, I'll change the part of the introduction that says: Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her. ...to say: Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her, or that she has verified that the contributed code violates no rights. Which means that we're going to take you up on your suggestion for encouraging small patches. I just added this to the FAQ: 8) Does someone have to jump through all these legal hoops just to submit a small patch? The contributor agreement certainly is a heavy process for someone that wants to make a small contribution, such as a patch. These contributions are just as important to the health of an open source project as major code work. Thus, Zope should encourage patch contributions, not create an enormous disincentive. At the same time, integrity of the code base needs to be maintained. For small contributions, simply supply them through a communications channel such as the bug tracker or the mailing lists. Alternatively, contact a committer or ZC directly. A committer will then review the patch and assume the legal issues of committing it themselves. Likely they will contact the patch submitter and get a confirmation that the patch can be used. The committers will have some guidelines on recognizing when it is reasonable to accept a patch. It should be clear when something has little basis for being deemed intellectual property, versus a major change with advanced algorithms. In your note, you mentioned: I suppose that I could assign them those rights, but personally I find that idea repugnant since I don't believe in intellectual property grin. (Hmm. If I put my stuff in the public domain, how would that play in?) Repugnancy aside :^) your second comment is on the mark. It isn't so much that you need to assign and lose ownership. Rather, the committer needs to ensure that they aren't violating your rights. We'll probably work up some boilerplate such as, I'm going to commit your patch to Zope. It's going to be available under the ZPL and the joint ownership model of the Zope Contributor Agreement. Please respond agreeing that you understand the ZPL, the joint ownership model, and allow this contribution under these terms. How does that sound? --Paul R. David Murray wrote: On Thu, 20 Sep 2001, Paul Everitt wrote: So, let's begin what I'm sure will be a lively and illuminating discussion. :^) First, would it be possible to put up a copy of the Contributor Agreement in html format? If you feel the only legal version for signing is the PDF one fine, but it would be a lot easier for people to check it out if there is an html version to read. Second, I suppose you should be aware of my biases before reading anything more. I don't believe in intellectual property, either copyright or patent. On the other hand, they are currently the law of the land; and, within what seems to me to be fair use kinds of standards, I try to respect copyrights while encouraging people to use vehicles that make use of as few of the restrictions imposed by copyrights and patents as possible. (You will guess that I am *not* a fan of the GPL, though I consider it far superior to a traditional copyright grin.) Also, I am not a lawyer and don't pretend to be very up on the subtleties of copyright law, so my concern may turn out to be naive. I very much like the intent stated in the Introduction, that of getting maximal rights into the hands of both the contributors and Zope Corporation to do things in the future with the code without having to get an endless set of sign-offs. However, I have a concern about the Agreement that isn't covered in the Introduction or the FAQ. I'm worried that the Agreement may exclude us from some of the benefits of the bazaar model of open source development. My key concern is summed up in this statement from the Introduction: Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her. The actual agreement does *not* say this, but essentially it does require it, since the things the committer has to swear to in submitting the code are very difficult to swear to unless he or she is the author of the code. Now, I have only contributed small amounts of code to Open Source projects so far. But I'm sure there are a lot more people out there who have only contributed small amounts than those who have contributed whole modules, and that there are even fewer people who do so much work that jumping through these kinds of legal hoops, and agreeing to a certain amount of liability, is worth while. In the cases where I have
Re: [Zope-dev] Vulnerability in Zope
Do others consider this a vulnerability? While it reveals more information than people might want, I'm curious about scenarios under which it could be exploited. If any of you know of something *specific*, meaning it's a genuinely exploitable vulnerability, please email me or Brian Lloyd ([EMAIL PROTECTED]) directly, rather than explain to the world how to do it. --Paul ALife wrote: Found vulnerability: retrieve a full path to local files in Zope. ---[ Example 1 (Linux): telnet www.zope.org 80 PROPFIND / HTTP/1.0 F G H J K L HTTP/1.0 500 Internal Server Error Server: Zope/Zope 2.3.2 (source release, python 1.5.2, linux2) ZServer/1.1b1 Date: Mon, 10 Sep 2001 15:38:59 GMT Content-Length: 7058 Ms-Author-Via: DAV Bobo-Exception-File: /usr/local/base/Zope-2.3.2-modified/lib/python/OFS/Property Sheets.py Bobo-Exception-Type: TypeError Content-Length: 7058 Ms-Author-Via: DAV Bobo-Exception-File: /usr/local/base/Zope-2.3.2-modified/lib/python/OFS/Property Sheets.py Bobo-Exception-Type: TypeError Content-Type: text/html Bobo-Exception-Value: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional// EN http://www.w3.org/TR/REC-html40/loose.dtd; HTML HEAD TITLEWelcome to Zope.org/TITLE link rel=stylesheet href=http://www.zope.org/zope_css; type=text/css /HEAD BODY B Bobo-Exception-Line: 369 ... !-- Traceback (innermost last): File /usr/local/base/Zope-2.3.2-modified/l ib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/ba se/Zope-2.3.2-modified/lib/python/ZPublisher/Publish.py, line 187, in publish F ile /usr/local/base/Zope-2.3.2-modified/lib/python/Zope/__init__.py, line 221, i n zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /us r/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/mapply.p y, line 160, in mapply (Object: PROPFIND) File /usr/local/base/Zope-2.3.2-mo dified/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: PR OPFIND) File /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/Resource.py, line 222, in PROPFIND (Object: ApplicationDefaultPermissions) File /usr/loc al/base/Zope-2.3.2-modified/lib/python/webdav/davcmds.py, line 219, in apply Fi le /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/davcmds.py, line 219, i n apply File /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/davcmds.py, line 219, in apply File /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/d avcmds.py, line 219, in apply File /usr/local/base/Zope-2.3.2-modified/lib/pyth on/webdav/davcmds.py, line 175, in apply File /usr/local/base/Zope-2.3.2-modifi ed/lib/python/OFS/PropertySheets.py, line 369, in dav__allprop (Object: Virtu al) TypeError: (see above) -- Host has closed connection. ---[ Example 2 (Linux): telnet www.zope.com 80 / HTTP/1.0 or NOTREALCOMMAND / HTTP/1.0 HTTP/1.0 404 Not Found Server: Zope/Zope 2.3.2 (source release, python 1.5.2, linux2) ZServer/1.1b1 Date: Fri, 21 Sep 2001 12:51:48 GMT Bobo-Exception-File: /usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/H TTPResponse.py Content-Type: text/html Bobo-Exception-Type: NotFound Bobo-Exception-Value: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional// EN http://www.w3.org/TR/REC-html40/loose.dtd; HTML HEAD TITLEWelcome to Zope.org/TITLE link rel=stylesheet href=http://www.zope.org/zope_css; type=text/css /HEAD BODY B Content-Length: 5845 Bobo-Exception-Line: 547 ... !-- Traceback (innermost last): File / usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/Publish.py, line 223, i n publish_module File /usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher /Publish.py, line 187, in publish File /usr/local/base/Zope-2.3.2-modified/lib/ python/Zope/__init__.py, line 221, in zpublisher_exception_hook
Re: [Zope-dev] questions about writing a DA
I just took a look at ODBC Socket Server, which I had never seen before. Pretty interesting! Here's some comments. 1) It looks like socket server opens a new socket for processing every request. In this respect, it goes against one of the benefits of database adapters, which keep a persistent connection. 2) Architecturally, socket server is very similar to web services. See the fishbowl proposal at dev.zope.org for more info. Thus, the approach that Zope would do for web services might have some similarity to what you'd like to do. Alternatively, take a look at the adapter for Ultraseek search engine at http://www.zope.org/Members/brianh/UltraseekDA. It gives a model that might be useful to you. 3) Zope's approach of having separate objects that handle database connections provide the benefit that regular objects can't just fire up socket connections. You want a model that helps prevent all of Zope's threads from being stuck waiting on responses to socket requests. 4) SQL Methods provide some useful and important machinery for your socket server approach. First, I think you want site developers to think your thing is exactly the same as a regular SQL Method. Also: - You likely want to keep the arguments list approach, to prevent people from inserting malicious data into the SQL requests. - Even more than with current database adapters, you want to retain the caching feature in SQL Methods. - Shoving the results into the Recordset code is something you might want to keep. - Etc. Good luck, this looks like a useful project! --Paul StevenLee wrote: hi,all I have got several questions here,and maybe you can give me some advice. What I am trying to do is write a product which can communicate with ODBC Socket Server, a win32 server application that allow applications to have access to Data Sources managed by Windows ODBC DataSource Administrator. And now a class written in python can communicate with ODBC Socket Server. BTW,the class mentioned above handles the connection to the server,sending SQL statement,and Receiving results. As far as I know, in Zope,to access Data Sources,one must create a Database connection and ZSQLMethods associated with it to get the results. (but I have doubt about this, IMHO,there must be some other way to do so,but what is it.). Now,I am rather confused about how to solve the problem. First,is what I need to write a DA? or just a common product? Second,if it's a DA, how can I use the existing class? I have read the article named how to write a DA in the how-tos,but it is quite abstract to me. Third,where can I find more about the DataBase Connection and ZSQLMethod ? especially on how they work together to access databases. OK,I am not sure whether I have made me understood, in fact,I am not quite clear myself. if you have any questions about that,I will reply ASAP. thanks for your great patience,I will be grateful if you can give me some advice. thank you! Best Wishes yours sincerely Steven Lee f? ?j)e?Y+?m?^8.??+-???:)y?6?+(7))(7)l1.?r??^?^vX?+-?:)z???f?X?)?q+-?:)z???f?X?)??pe== ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
This is a good point, and one that we need to settle on pretty quickly. The language is an artifact from the Mozilla contributor form, which served as the starting point for this. We intended to follow it, but with the advent of the joint ownership idea (which came late in the process), we might want to revisit it. Either way, I'll get an answer for you, thanks! --Paul Morten W. Petersen wrote: On Thu, 20 Sep 2001, Paul Everitt wrote: So, let's begin what I'm sure will be a lively and illuminating discussion. :^) First man out? :-) Will a ZPL-ish license [1] be accepted (declared, ref. paragraph 4 of the Zope Contributor Agreement) by the Zope Corporation? [1] http://www.thingamy.org/tpl -Morten ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
I'll reply in more depth later (on the way out for my b-day dinner), but in short: I think the issue of overhead on patches is something for us to consider. We won't do something that breaks the integrity of the code base, but there might be ample discussion directions. Thanks! --Paul Dieter Maurer wrote: R. David Murray writes: ... So, the many small contributions that make a bazaar software project tend rapidly toward high quality, which is one of the things I got the impression you are trying to achieve by opening up the CVS repository, may not materialize under this Agreement. We'll have just about the same situation we have now, except that there will be more committers and therefore, one hopes, an increase in the pace of (controlled) change. An improvement, yes, but can we do even better? I think (and indeed I really hope) that your anxiety is not founded. The Zope Contribution Initiative took Python as model. There, you have beside contributors a bug tracking system where problems can be reported and patches posted to. I do not know the details of Python development process, especially the legal agreements behind it. But somehow, it seems to work... Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL
With great trepidation, I add a post to this thread. As Barry has mentioned, this has all been discussed a LOT. I'll try to summarize and clarify a few points: 1) I wanted to specifically address something in Michael's post here. We fully expect people to profit from Zope, even if that means for-fee, intact redistributions. They simply have to provide credit. Others may have a different philosophy, but that's ours. This is similar in some regards to Perl's and Apache, I believe. 2) We specifically expect to produce a packaged version of Zope. It's clear that it's the only way to appeal to the mainstream market. We hope others do the same. 3) Regarding other posts, our license is nearly identical to Apache's license, close enough legally to say it is the same. Therefore, to say Zope isn't free enough is to say Apache isn't free enough. Anybody that says that loses a fair amount of credibility, at least with me. Apache is an example of a crossover success (open and commercial) that I think provides a fantastic role model. 4) Any changes in the license are likely to be more in the direction of an Apache-style license. No approach pleases everyone, unfortunately. We do the best we can. --Paul Michael R. Bernstein wrote: On 26 Jun 2001 10:29:39 +1000, Anthony Baxter wrote: Michael R. Bernstein wrote Unless I've misunderstood something (which is certainly possible), DC doesn't seem to have anything to lose by switching from a BSD style license to the GPL (or a GPL style license with an additional optional attribution clause), and quite a bit to gain. They will probably lose developer mindshare. Given how important this is to Zope's growth (and to DC's growth, as a result), this is far far more important than the karma from switching to the far less flexible GPL You're right. I hadn't considered that the ZPL needs to be 'proprietary compatible' so far as add-on products are concerned. perhaps the LGPL would suffice, as that would permit creating proprietary Zope products. But I won't be entirely happy if the ZPL permits proprietary third-party redistributions of Zope itself. Your argument seems to be that DC would want to control other companies ability to make distributions derived from Zope - unless they've been hiding this nefarious plan from the community, this doesn't seem to be an objective for them. Heh. I guess I shouldn't have stuck that in there. An argument I've occasionally heard for BSD-style licenses is that the original (usually corporate) author wants to be able to make proprietary releases based on other peoples contributions. The argument for NPL-style licenses is that they (the original author) want to be the *only* one with such a privileged position. DC has never indicated that either of these was important to them. As far as a contributor to Zope wanting to keep their work free, then if the ZPL is GPL compatible, they can make their components GPLd. True. Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL
I'd like to add a quick clarification, then I'll reply more later. Frederico brought up a good point that indicated I wasn't clear. It is a *desire* of ours to be GPL-compatible. Not a requirement, as it can be awfully tricky, complicated, and time-consuming to get there. But we've told people that we're intending to give it a shot. --Paul Federico Di Gregorio wrote: hi, i wanted to draw myself from this thread before annoying the whole list, so i'll take paul mail as an excuse to write some final comments. On 27 Jun 2001 09:06:16 -0400, Paul Everitt wrote: 1) I wanted to specifically address something in Michael's post here. We fully expect people to profit from Zope, even if that means for-fee, intact redistributions. They simply have to provide credit. Others may have a different philosophy, but that's ours. This is similar in some regards to Perl's and Apache, I believe. i think that nobody (ever gpl-oriented people like me) have anything against making profit from free software. profit means more time and resources to write even better software, profit is *good*. 2) We specifically expect to produce a packaged version of Zope. It's clear that it's the only way to appeal to the mainstream market. We hope others do the same. that's a business strategy. good or bad has nothing to do with licensing. i wish you all possible luck with a packaged version of zope. i'll even buy one if includes a well-written well-printed manual about zope internals... ;-) 3) Regarding other posts, our license is nearly identical to Apache's license, close enough legally to say it is the same. Therefore, to say Zope isn't free enough is to say Apache isn't free enough. Anybody that says that loses a fair amount of credibility, at least with me. Apache is an example of a crossover success (open and commercial) that I think provides a fantastic role model. again, i agree. apache. *is* free. zope *is* free. end of the argument. 4) Any changes in the license are likely to be more in the direction of an Apache-style license. let me try to explain why this is bad and a gpl-compatible license will be better. a lot of people, like me, wants other use their work, even for making money. but we want something back. this is why the gpl is good. if you use my work you can: 1/ release your sources under a gpl compatible license; or 2/ give me some money for an alternate license: this is good because i'll use the money to write even more software (see it as an exchange, you can keep your sources propietary but you finance someone for writing free code that will be made available to the community.) the main problem with licenses like tha apache one is that they allow people to use public, free code without giving *anything* back. with its current license dc is forcing *me* to release under a license that i don't like (ZPL) because if i release my software unsed the gpl nobody will be able to redistribute it. this will make more and more people like me abandon zope first or later (i hope later). the current license surely does not push away companies that don't want to open their sources but what good come from that? nothing. no software for us and no money for dc. what if the zpl would be gpl-compatible? the situation will be reversed. a lot of people will continue to write and distribute zope products and the occasional company not wanting to release will pay dc and other developers for an alternate license. this will make *everybody* happy. as i said before the *worst* case for zope going gpl-compatible is the no-harm situation, while going apache-like is a little harm to some entusiast developers and surely no good. i finished. no more mail on this argument, and sorry for my bad english, i wrote this one in an hurry... federico ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Announce] API Documentation Fishbowl Project
Hmm, I'm surprised that 2 days has passed with no comment from zope-dev and no comments in the Wiki. I hear constant complaints about lack of a polished API. I expected this post to generate lots of interest. What say ye, zope-dev? Is this something we should be doing, or would you prefer a different documentation activity to have priority? Is the proposed solution agreeable? For all of you that have chimed in about the API, here's a chance for you to get involved and help make it a strong effort. Help!! :^) --Paul Amos Latteier wrote: Fellow Zopistas, Mike Pelletier and I are working on a project to improve Zope's API documentation. Details are now publicly available in the fishbowl. (Actually it's been public for a while, but this is the first announcement of the project.) http://dev.zope.org/Wikis/DevSite/Projects/APIDocs I encourage you to check it out and leave your comments, criticisms, and suggestions. This project aims to improve the life of Zope developers, so please help us make sure we're not off base. For the project to succeed it must meet *your* needs. Thanks! -Amos -- Amos Latteier mailto:[EMAIL PROTECTED] Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANNOUNCE: Zope 2.4.0 alpha 1 released
As one more example, Zope.org is currently at 4.8 Gb on FileStorage. --Paul R. David Murray wrote: On Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote: My impression is that FileStorage implements a 32-bit id-type-thingy somewhere (look at ZODB docs, I think there is something about this somewhere), which limits it (in addition to the Linux kernel ext2 fs limit), to 2GB. With 7.5 GB, I'd use a more advanced storage like the new - well, not quite released ;) - Berkeley (libdb3 based) storages, though I haven't tried anything like that myself... FileStorage does *not* have a 2GB limit. The only 2GB limit is the old Linux filesystem limit. I know this, because I've had 2GB Data.fs files on FreeBSD. --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANNOUNCE: Zope 2.4.0 alpha 1 released
Lalo Martins wrote: By hoping that EC will go away soon, I assume they mean the PythonLabs folks are working on fixing this for once in Python itself. Right? That is correct. The point is, ExtensionClass machinery will go away but the functionality would remain, if Python changes in the future to make it unnecessary. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] License issues
Some quick points on this. First, feel free to talk on this list about ways that Zope developers can license their stuff. It's a constructive discussion, and since I'm not a Zope developer, I can ignore it. :^) Second, regarding the licensing of Zope itself, ChrisP is right that I'm the guy on that. Or more specifically, Hadar Pedhazur (our board chairman) and I run the zope-license email alias. He and I had previously decided that, after the round closed, we'd take a fresh look at our licensing strategy. Basically, we'd like to get out of the business of having our own license, and we're open to the idea of a license that is more GPL-friendly, in the spirit of Apache, Python, etc. Thus, continue discussing what you need to do your jobs and give us some time to hash out a proposal. Thanks! --Paul On 14 Nov 2000 09:29:11 -0800 Simon Michael [EMAIL PROTECTED] wrote: Juan, thanks for shining some light towards this murky area. Maybe ZWiki and other zope products need to be LGPL or dual-licensed, maybe the zope license can use some refinement. I for one won't know without seeing some enlightened discussion of the issue. This stuff is unsexy but important. Best regards, -Simon ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Do I really understanding caching?
Andy McKay wrote: What problem are you trying to solve -- response time, memory usage, disk usage? All of the above :) Describe some of the symptoms back on the list and let's talk about it there. For instance, you can trade RAM for performance by adjusting knobs on the catalog. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] HiperDOM xmlc
I'm surprised that no one responded to this. (Or maybe people did and our continual email server problems have lost it.) I'd like to congratulate Hiperlogica, because they have (ding ding ding) the _right answer_! :^) Seriously, we at Digital Creations have been quietly formulating a proposal on this since Amos put up the template proposal in dev.zope.org. I floated some trial balloons at EuroZope and it's clear there's some consensus. Our "XHTML Templates Proposal" is at: http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal Since Wiki is having a tough time on the list here lately, I'll post the text in a message in just a second. To summarize, we at DC at least think that Hiperglocia is on to the right thing and we'd like to indicate support for that direction. --Paul [EMAIL PROTECTED] wrote: We (I and Hiperlogica, a company I consult with) have been developing a template renderer with similar intent to xmlc (be based on XML/DOM, allow the template to be previewed and edited using tools not aware of the format, such as xHTML editors, and enforce presentation/logic separation). As the project is somewhat on hold while we have more pressing issues, I decided to share the current (rather kludgy) prototype with the community. It is at http://www.zope.org/Members/lalo/HiperDOM/ On Mon, Sep 11, 2000 at 02:06:08PM +, Jason Spisak wrote: Zope Devers, THis is going to seem strange coming from someone who hasn't been on the list in a long time, but I was at the Linux Expo in San Jose, and sat in on a Web app talk. Lutris was in charge of the panel, and they talked about xmlc. I went to their booth and asked about it. I think it could be the best way to get hard-core python people to jump on zope's band-wagon, and stop the dtml frowning. If you who are in the know about zope have time, please read a quick bit on what it is. http://xmlc.enhydra.org Especially the tutorial: http://staff.plugged.net.au/dwood/xmlc/index.html Is there any obvious reason why Zope wouldn't benefit tremendously from this design and programming separation and pure python boost? []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] DISCUSS: XHTML Templates proposal
Howdy folks. As advertised in my last email, below is our Fishbowl Proposal on a new template architecture. Some notes: 1) This mostly replaces DTML. As mentioned, the goal isn't necessarily to get DTML removed from Zope. Rather, most of the audience will see it little or none of the time. 2) This proposal has gotten more internal DC scrutiny from a requirements perspective than anything we've done. The proposal has been rewritten four times. 3) The original version of this forced the connection between reinventing the data tier (documents) and the presentation tier (templates/pages/stylesheets). We eventually found the way to decouple the connection, but we still need to write a documents proposal. 4) What this really, really needs right now is extensive user documentation with screenshots written *before* the software. This is where we got stuck. Docs are the fastest way to confront the myriad of usage details. 5) Our proposal is a little more ambitious than HiperDOM (we have a concept of "components" that are hinted to but not explained). But for now, HiperDOM is a good basis for exploring XHTML Templates. 6) I'm still not convinced template is the right word. Unfortunately I'm less convinced at any alternatives. Whatever is chosen, it must feel "normal" to the vast majority of the audience. Cheers! --Paul XHTML Template Architecture Zope should increase usability and promote separation of tiers by moving to a presentation and data architecture. Site Designers will author and round-trip presentation objects in familiar tools. Combined with the Document Architecture, this proposal establishes the fundamental content and presentation architecture for Zope. Note on status The great folks at Hiperglocia have already produced something quite similar to what is discussed here. Their Zope product is called "HiperDOM", http://www.zope.org/Members/lalo/HiperDOM/. Note On Jargon The choice of term for the presentation object has been contentious. Right now the list of choices include: template, view, page, or stylesheet. This proposal doesn't make the decision on the jargon. Rather, the tier is usually refered to as the presentation. When a choice has to be made, such as the Architecture section, Template is used as the temporary choice. Problem Zope currently has a model of DTML Documents and DTML Methods as the basic data and presentation tiers. However, this model is confusing, doesn't promote separation of tiers, and doesn't work with popular web design/authoring tools. For the presentation tier, Site Designers are faced with an idiom in which well-formed HTML is split between two "files" (standard_html_header and standard_html_footer). Also, the presentation mockups are "taken away" by programmers who insert a bunch of alien tags that don't present anything on the screen of the web design tool. Worse, DTML is fundamentally impossible to edit directly by classic tools due to the "source vs. rendered" issue. That is, when a Site Designer wants to edit a piece of DTML, they will get the *rendered* version of the DTML for editing, where all the DTML tags are expanded into HTML. In summary, there is a tremendous usability issue, both conceptual and in practice. There are additional problems: o DTML is considered a "proprietary" language o Data needs to have different presentations used under different conditions o Consulting practices need a way for customers to start seeing screen results immediately without having the programmer "steal" the templates by converting them to something alien Goals The goals of the Presentation Architecture are: o Clear separation of presentation, data, and logic with clear concepts in Zope for these tiers and audiences o Increase usability by allowing round trip presentation with common tools and familiar concepts o Allow those presentation tools to work by having well-formed markup (e.g. no separation into header and footer) o Supplant "proprietary" markup language (DTML) in presentation tier by leveraging standards (XHTML) (Note: "eliminate" isn't the target as it might not be feasible in 100% of the cases) o Match the appropriate level of capability currently in DTML usage o Simple presentation reuse within reach of standard tools Solution Zope should move to an architecture with clear separation of presentation, data, and logic, with clear concepts in Zope for these tiers and audiences. The presentation tier will get a tremendous usability increase by allowing round trip presentation with common tools. This also ensures that Site Designers finish with the same stuff they started with, meaning the programmers don't come in and cast their work into "code". The architecture should make sure those presentation tools are effective by having well-formed markup (e.g. no
Re: [Zope-dev] DISCUSS: XHTML Templates proposal
[EMAIL PROTECTED] wrote: IMHO, view, page, and stylesheet don't make the grade due to conflicts/confusion with unrelated technologies (e.g. MVC, "server pages", CSS, etc.). On the other hand, reading the "What is styles?" material at: http://www.w3.org/Style/ ...makes me think that the goals of the people using these things (site designers) are the same as the goals of the audience described for stylesheets. That is, these are things that control the presentation. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] PLEA: Provide feedback on OracleStorage
Hello sports fans. Last week we released a beta of OracleStorage. There was a pretty strong drumbeat in Zopeland for us to go ahead and get this out. We spent some extra time on the installation process and instructions to make sure it was straightforward to use. We at DC would like to get OracleStorage hardened as fast as possible. Thus, I have a serious of requests: a. If you are interested in it, please download it this week and give it a shot. b. If you downloaded it, please send me a note and tell me so. c. If you find any bugs with it, please file something in the Collector. We'll make sure there's a keyword for OracleStorage. d. If you have a general question, request, or discussion, start a thread here in zope-dev. My indebtedness goes out to anybody that can help us on this. Thanks! --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
