Re: [Zope-dev] Re: [Zope-dev]ZPL and GPL licensing issues
On Sun, Jun 24, 2001 at 07:49:40PM -0700, ender wrote: On Saturday 23 June 2001 11:20, Erik Enge wrote: [Simon Michael] | Now you're talking. Seconded. Me too! i'd very much like to see a GPL compatible zope license as well, both for products i create and to integrate with third party gpl products. would a petition be useful? As much as I would appreciate it if DC was able (from an economic viewpoint, this it) to release Zope under the GPL, I think that it's much more important that they release Zope under a GPL compatible license (which is definitely a very different thing). If this is what you meant, I agree with all of you ;-) Gregor ___ 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] Speed up the learning curve
On Sun, 24 Jun 2001, Dieter Maurer wrote: Rene Pijlman writes: A suggestion to cut the Zope learning curve down by half a day... When the programmer forgets the docstring in a method of a Python-based product, instead of saying Sorry, the requested resource does not exist. Zope could say: Sorry, this method has no docstring. Doesn't it do precisely this when you run Zope in debug mode? I didn't loose half a day to this one, but I did loose at least fifteen minutes. And I'm a fairly experienced Zope/Python programmer. Furthermore, I do not in general run in debug mode during development. Most of the time I am developing with continual customer review, and the customers get confused and worried if the tracebacks appear on the error pages, so it's easier just to not use debug mode. I do, however, run with stupid log enabled. So if it is unacceptable to have a more informative non-debug message, it would be nice to have something show up in the stupid log. --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 )
Re: [Zope] Re: [Zope-dev] Zcatalog bloat problem (berkeleydb is a solution?)
Chris McDonough wrote: This purpose aligns well with those of the ArmoredCatalog proposal as well.. see http://dev.zope.org/Wikis/DevSite/Proposals/ArmoredCatalog . But even using such a lazy catalog awareness, you might get into trouble. Using the ZCatalog's find objects function, I hit the limits of my Linux box: 640 MB RAM were not enough... This should not happen. :-( Just to add another data point, we're still having issues if we catalog-as-you go when trying to recreate our mailing list archives in Zope. As I understand it, the guys managed to get it to work by importing 28,000 odd message and then indexing, rather than indexing as each one was added. This was using Zope 2.3.2, should it be expected? cheers, Chris PS: Andy D was going to post this but he went home ill, I don't think that was ZCatalog related ;-) ___ 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] Zcatalog bloat problem (berkeleydb is a solution?)
Chris McDonough wrote: A solution might be a kind of lazy catalog awareness: Instead of mangling a new object through one or more catalogs when it is created, this object could be added to a list of objects to be cataloged later. This way, the transaction to insert a new object would become much cheaper. I'm working on this, but right now it is quite messy. (I'm new to Python and Zope, and hence I'm stumbling over a few, hmmm, trip-wires...) This purpose aligns well with those of the ArmoredCatalog proposal as well.. see http://dev.zope.org/Wikis/DevSite/Proposals/ArmoredCatalog . I'm afraid that I did not understand much of the discussion on this page. (But I don't intend to become a ZODB developer, so I'll simply ignore it...) But if I'm right, this lazy catalog awareness would mainly mean that ArmoredCatalog gets official API calls (1) to add object to an update or delete list and (2) to index/unindex the objects in these list. I think that this would be really useful. But even using such a lazy catalog awareness, you might get into trouble. Using the ZCatalog's find objects function, I hit the limits of my Linux box: 640 MB RAM were not enough... This should not happen. :-( I'm really disappointed that the bloat and memory consumption issues are still plaguing the ZCatalog. At one point, I really thought we had it pretty much licked. I suppose this was naive. A few weeks ago, I've posted this (admittedly not fully cooked) patch to this list, but did not get yet any response. I apologize for this. We have a fairly formalized process for handling feature-ish collector issues, and this hasn't come round on the guitar. I'm beyond disappointed that people are still having unacceptable bloat, enough that something like this patch needed to be submitted. It's disheartening. Chris, never mind :) It's also my fault: I'm contended with reading a mailing list (and sometimes making more or less clever comments), and I know that Zope has far more elaborate discussion systems, like Wikis and fish bowls. Only that I'm too lazy to scan through all this stuff to find a better place for comments... And I know that it's fairly easy to miss a mail :) Abel ___ 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] DCOracle2 and SP problem
The situation: - Oracle 8.1.7 installed on a machine (excalibur) running SuSE Linux 7.0 (i386) - Kernel 2.2.16 (2). - Zope Version: Zope 2.3.3 (binary release, python 1.5.2, win32-x86) Python Version: 1.5.2 (#0, Jul 30 1999, 09:52:18) [MSC 32 bit (Intel)] System Platform: win32 installed on Windows NT 4.0 SP6a (lancillotto) - DCOracle2 (DCO2-NT-Beta3.ZIP) also installed on WinNT The installation standard of DCOracle2 do not run at first try, I moved the DCOracle2 directory from ZOracleDA (under $ZOPE_HOME/lib/python/Products) to $ZOPE_HOME/bin/lib and it run. I can run successfully queries from Z Oracle Databse Connections object's Test Page . But when I create a Z Oracle Stored Procedure object (Procedure name GET_ID_UTENTE successfully compiled on Oracle - and successfully running with old versione DCOracle1 from another Zope installation - but on the Linux (excalibur) machine) the Procedure Description say that: function GET_ID_UTENTE.GET_ID_UTENTE returns OUT NUMBER, has arguments: USERACCOUNT IN VARCHAR2 and the test page return this error message: Error Type: DatabaseError Error Value: (6550, ORA-06550: line 1, column 28:\012PLS-00225: subprogram or cursor 'GET_ID_UTENTE' reference is out of scope\012ORA- 06550: line 1, column 7:\012PL/SQL: Statement ignored) Any ideas? Thank you in advance. Giovanni Coi _ Prometeo srl - The Software Experience Coi Giovanni Voice : +39 (041)5701366Via Giudecca 15 Fax : +39 (041)570100530035 MIRANO (VE) - ITALY e-mail: [EMAIL PROTECTED] http://www.prometeo.it ___ 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] Re: [Zope-dev] Zcatalog bloat problem (berkeleydb is a solution?)
Chris McDonough wrote: This purpose aligns well with those of the ArmoredCatalog proposal as well.. see http://dev.zope.org/Wikis/DevSite/Proposals/ArmoredCatalog . But even using such a lazy catalog awareness, you might get into trouble. Using the ZCatalog's find objects function, I hit the limits of my Linux box: 640 MB RAM were not enough... This should not happen. :-( Just to add another data point, we're still having issues if we catalog-as-you go when trying to recreate our mailing list archives in Zope. As I understand it, the guys managed to get it to work by importing 28,000 odd message and then indexing, rather than indexing as each one was added. This was using Zope 2.3.2, should it be expected? No. ___ 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
On 25 Jun 2001 10:26:10 -0400, Shane Hathaway wrote: According to management, there's a zope-license list somewhere and we expect to move to a GPL compatible license. Paul says: I think the goal should be for Zope and Python to converge on the same license, with perhaps the new license being some off-the-shelf license like Apache's. Hmm. So a BSD style license, then. Are there currently any Zope-derived distributions that are proprietary (third-party or DC's)? If not, does DC anticipate there being this kind of third-party proprietary derived distribution in the future? Other than keeping the door open for this eventuality, is there any other reason to choose a BSD style license over the GPL? As I see it, BSD style licenses ensure that anyone can make proprietary derived distributions. They are very similar to public domain in this regard. The GPL ensures that no-one can make proprietary derived distributions, except that the copyright holder always has the option of releasing under another license if they wish, so dual licensing or changing the license is always an option *if you have contributors assign the copyright of their contributions to you*. NPL (Netscape Public Licence) style licenses try to make it possible for no-one to make proprietary redistributions *except the original author*. The license generally requires contributors to allow the original author to make proprietary redistributions using their contributions even without copyright assignment (or that assignment is implicit in the contribution). Note that re-licensing (or dual licensing) would still require contributors to assign copyright just as with the GPL. Given that DC is the copyright holder for Zope, they would do well (IMO) to consider relicensing Zope under the GPL or LGPL, as that would force anyone who wished to redistribute a proprietary version of Zope to negotiate a separate license with DC, actually strengthening DC's position in that regard, while generally ensuring that contributors work would remain GPL. If some contributor did not wish to let DC relicense their contribution, they could simply not assign the copyright to DC. DC has the option of not adding the contribution into the distribution, or of removing the contribution from any relicensed version. So. The current ZPL is essentially a BSD style license with the optional attribution clauses, and a mandatory advertising clause (although there's an escape hatch too). It seems that the mandatory advertising clause is most applicable when someone creates a proprietary derived distribution of Zope. If there are none such (I'm not aware of any), then the clause is unneccessary. 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. Note that this is a different option than merely switching to a BSD style license that is 'GPL compatible'. 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 )
Re: [Zope-dev] ZPL and GPL
On Mon, Jun 25, 2001 at 12:22:32PM -0700, Michael R. Bernstein wrote: Other than keeping the door open for this eventuality, is there any other reason to choose a BSD style license over the GPL? ... 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. I personnally would love to see both Python and Zope be GPLed. However we should take into consideration the fact that this would mandate that any Zope product should be GPLed too, since in the FSF view we link them to Zope. The same for Python C extensions, we would link them to a GPLed software (Python), so they would have to be GPLed too. That's why I'm pretty sure that unfortunately both Zope and Python would loose supporters if they were GPLed. bye, Jerome Alet ___ 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] RFC: How-To on subclassing Shared.DC.Scripts.Script.Script
I'm thinking here that subclassing Script is the way to go for any object that needs finer control on how it is called - and I'll say that of any class that doesn't just do index_html = HTMLFile(foo, globals()) So, I wrote a How-To. It's definitely not ready for prime-time, as I haven't actually used it to implement a class, but I think it's correct. I'd appreciate if people took a look at it and commented both on correctness and clarity/usefulness. It is at http://www.zope.org/Members/lalo/scriptclass-dev now; this is a ZWikiPage, so you can comment right there. The real address will be http://www.zope.org/Members/lalo/scriptclass when it's ready. []s, |alo + -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Brazil of Darkness (RPG) --- http://www.BroDar.org/ ___ 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: Zcatalog bloat problem (berkeleydb is a solution?)
(I removed [EMAIL PROTECTED].) On Mon, 25 Jun 2001, Giovanni Maruzzelli wrote: Any hints on how to manage something like? We use both textindexes, fieldindexes, and keywordsindexes (textindex on string properties, fieldindexes on boolean and datetime, keywordindex on strings). Maybe one kind of indexes is to be avoided? Erik, any toughts? Well, after ChrisM told me about the behaviour of CatalogAwareness, and I removed that from my classes, my ZCatalog bloatness has evaporated. I really can't see any major bloat-problem on either memory-consumption or disk-space. (That was with Zope 2.3.2b2.) Which is very good for me, but doesn't necessarily help you much. :) ___ 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
On 25 Jun 2001, Michael R. Bernstein wrote: Other than keeping the door open for this eventuality, is there any other reason to choose a BSD style license over the GPL? Yes. A commercial one; an imperative one. If I make a Zope Python Product, I must license it as GPL to be able to redistribute. That's just unacceptable in my eyes. (It would probably go against my personal beliefs to do that, but in the business-would you can't barge in with a hard GPL-attitude all over your face and expect people do readily do business with you. That's why we need a transition period; 'till the catch up with us.) I, for one, am quite convinced that most of the revenue Zope help companies create out there is done by proprietary Zope Python Products. With Zope under GPL this wouldn't be possible. (Me thinks.) 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. How do you suppose DC make their monies? I'm quite sure they can't license Zope under the GPL because they would intimidate their market too much with it (an assumption that could be wrong, naturally). Let's hope they go for a GPL-compatible one. I can't see what they would/could loose by using a BSD-style one, maybe you have some thoughts on that? ___ 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
On Mon, 25 Jun 2001, Shane Hathaway wrote: (Paul says:) I think the goal should be for Zope and Python to converge on the same license, with perhaps the new license being some off-the-shelf license like Apache's. Wow, lobbying the management team at DC is pretty easy ;-). It's good to see that things will be resolved; thanks Shane. ___ 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: Zcatalog bloat problem (berkeleydb is a solution?)
Part of the problem here is that if, in particular, you use the reindex_object method of CatalogAware, the database will grow unnecessarily even if the object hasn't changed. CatalogAware is arguably broken and should really not be used. I'd like to have the time to fix it, but fixing it implies taking time out that I don't have at the moment to test the changes, and *may* imply breaking it in slightly other backwards-incompatible ways that will cause people to scream. For instance, unfortunately, CatalogAware also uses the *url* of the object to index it, which is contrary to the way that newer Catalogs work (they index the physical path of the object). In the meantime, if you care at all about cataloging, do not use CatalogAware. Instead, manage the recataloging yourself and don't uncatalog a changed object before recataloging it during this manual operation, because this defeats all of the carefully set up change detection code (which may or may not still be working since I last worked on it ;-) - C Erik Enge wrote: (I removed [EMAIL PROTECTED].) On Mon, 25 Jun 2001, Giovanni Maruzzelli wrote: Any hints on how to manage something like? We use both textindexes, fieldindexes, and keywordsindexes (textindex on string properties, fieldindexes on boolean and datetime, keywordindex on strings). Maybe one kind of indexes is to be avoided? Erik, any toughts? Well, after ChrisM told me about the behaviour of CatalogAwareness, and I removed that from my classes, my ZCatalog bloatness has evaporated. I really can't see any major bloat-problem on either memory-consumption or disk-space. (That was with Zope 2.3.2b2.) Which is very good for me, but doesn't necessarily help you much. :) ___ 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] ZClass not in a Product
Maybe you search python.org for Guido's metaclasses article. It tells that a Python class can be both a class and an instance and that this view has interesting applications. You focus on the class aspects of a ZClass (a pattern for creating instances providing them with basic common infrastructure), while I stress the instance aspects. The fact, that you can manage ZClasses in the same way as other Zope objects, calls for similar structuring possibilities: taking them out of the centralized control panel and putting them anywhere in the site. That was the starting point of our discussion... I know about the duality of Python classes. I just don't see what I could really do with a ZClass in the instance space (reading this twice, see below for some possible examples). A totally different aspect is whether Zope should have something like an in-built support for virtual instances, i.e. sub-folders could be like full Zope instances, providing a local Products directory etc. THAT would make a lot of sense to me. But in general I am more in favor of getting things OUT of the instance folders than getting more stuff in. It makes absolutely no sense to me why the Zope management interface displays database adaptors, user folders, and actual content objects all in the same folder. The only thing these objects have in common is that they are living in the same namespace. Another problem ist that the Add lists get longer and longer. So why not have a separate tab for users, content, and technical things like database adaptors, or SiteRoots? O.k., what we get then is too many tabs, what there should be a clever way of changing the ZMI to a multi-level tab concept (main tabs and sub-menus). To come back to the ZClass question: I see and use them mainly as templates. That's what they are good for. So they should reside in a template folder. Right now, this folder is the Products folder. Maybe we need local Products/Templates folders, so that it is possible to have ZClasses that just work locally or that overload a base ZClass defined up in the tree. But what we definitely don't need is freely floating ZClasses. Another problem is that the ZClass implementation is really experimental. They work great, which is a miracle, but they are extremely slow, and a lot of things you'd need for effectively sub-classing ZClasses from others don't work. E.g. it is impossible to overload existing properties/porpertysheets, and acquisition does not work as expected either. Joachim ___ 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
On Tue, 26 Jun 2001 05:22, Michael R. Bernstein wrote: On 25 Jun 2001 10:26:10 -0400, Shane Hathaway wrote: According to management, there's a zope-license list somewhere and we expect to move to a GPL compatible license. Paul says: I think the goal should be for Zope and Python to converge on the same license, with perhaps the new license being some off-the-shelf license like Apache's. Hmm. So a BSD style license, then. Are there currently any Zope-derived distributions that are proprietary (third-party or DC's)? Absolutely! We use Zope as a core component in our product that's about to hit the shelves. If not, does DC anticipate there being this kind of third-party proprietary derived distribution in the future? Absolutely! We have several products in mind that are based on Zope. Other than keeping the door open for this eventuality, is there any other reason to choose a BSD style license over the GPL? I think I've answered that question. We will be distributing the entirety of the source code of all open-source components of our product. We cannot distribute the source code of our product - that would be sheer foolishness. We've invested about 2 man-years in the code, and we're not about to just give that away. Our investors would string us up! Richard -- Richard Jones [EMAIL PROTECTED] Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) ___ 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] RFC: How-To on subclassing Shared.DC.Scripts.Script.Script
It is at http://www.zope.org/Members/lalo/scriptclass-dev now; this is a ZWikiPage, so you can comment right there. The real address will be http://www.zope.org/Members/lalo/scriptclass when it's ready. Mmmh, after reading the how-to (quickly), I do understand for what you are using Script for. But when I started reading it, I wanted to learn more of how I could implement a new scripting language into Zope, such as a ZOQL (as mentioned on the SmartObjects mailing list: http://imail.iuveno-net.de/pipermail/smartobjects/), Tcl, XQuery or XPath. Even though your usage of the Script-class is unique and obviously useful, I think you should make a note, that will not describe how to implement another scripting language. But other than that, I learned something new. Thanks for the tutorial. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development Technical Project Management ___ 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
Jerome Alet wrote I personnally would love to see both Python and Zope be GPLed. Why? No really. Exactly what do you gain from this? Assuming Zope's license becomes GPL compatible, any packages you release you can choose to GPL. Why do you think having the GPL is a good thing for the core package? Ideological reasons? How does releasing under the GPL make the world a better place? Anthony, who's seen too much of the GPLd-for-GPLs-sake. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
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. 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. 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. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] RFC: How-To on subclassing Shared.DC.Scripts.Script.Script
On Mon, Jun 25, 2001 at 06:36:30PM -0500, Stephan Richter wrote: But when I started reading it, I wanted to learn more of how I could implement a new scripting language into Zope, such as a ZOQL (as mentioned on the SmartObjects mailing list: http://imail.iuveno-net.de/pipermail/smartobjects/), Tcl, XQuery or XPath. Even though your usage of the Script-class is unique and obviously useful, I think you should make a note, that will not describe how to implement another scripting language. But other than that, I learned something new. Thank you :-) I don't think I could teach something as generic as this; the process would be completely different for each language, and depend on your interpreter. For starters, PythonScript and ZopePageTemplates are completely different. The classes to add new scripting languages would be similar up to the point I described in my How-To, I'm afraid. Up from there, it's you and your interpreter. []s, |alo + -- Esvazie sua mente, pequeno gafanhoto. Nós temos muito o que aprender... mas primeiro... Primeiro você terá que desaprender o que acha que já sabe. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp Brazil of Darkness (RPG) --- http://www.BroDar.org/ ___ 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] getattr for non-Folderish item
Johnson, Michael (MIJOHNSO) writes: ... getattr does not work for attributes of inherited ZClasses ... getattr does no special things for folderish items. It simply accesses the attributes of an object in case, you can not use the attribute access syntax object.attribute because either the attribute name does not follow Python name syntax or is not constant. Furthermore, it does not care, whether the attribute is defined in the objects class itself or in an inherited class. Thus, getattr(self,your_attribute) should work. If not, something else is wrong (there is not attribute with name given be your_attribute). 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 )
[Zope-dev] Zcatalog bloat problem (berkeleydb is a solution?)
Hello Zopistas, we are developing a Zope 2.3.3 (py 1.5.2) application that will add, index and reindex some tens of thousands objects (Zclass that are DTMLDocument on steroids) on some twenty properties each day, while the absolute number of objects cataloged keeps growing (think at content management for a big portal, where each day lots of content are added and modified and all the old content remains as a searchable archive and as material to recycle in the future). This seems for some aspects a task similar to what Erik Enge impacted couple a weeks ago. We first derived from CatalogAware, then switched to manage ourselves the cataloging - uncataloging - recataloging. The ZODB still bloat at a too much fast pace. ***Maybe there's something obvious we missed***, but when you have some 4thousands object in the catalog, if you add and catalog one more object the ZODB grows circa a couple of megabyte (while the object is some 1 k of text, and some twelve boolean and datetime and strings properties). If we pack the ZODB, Data.fs returns to an almost normal size (so the bloat are made by the transactions as tranalyzer.py confirms). Any hints on how to manage something like? We use both textindexes, fieldindexes, and keywordsindexes (textindex on string properties, fieldindexes on boolean and datetime, keywordindex on strings). Maybe one kind of indexes is to be avoided? Erik, any toughts? We are almost decided to switch to berkeleydb storage (the Minimal one) to get rid of the bloating, we are testing with it, but it seems to be discontinued because of a lack of requests. Any light on it? Is it production grade? -giovanni ___ 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] Zcatalog bloat problem (berkeleydb is a solution?)
Giovanni Maruzzelli wrote: Hello Zopistas, we are developing a Zope 2.3.3 (py 1.5.2) application that will add, index and reindex some tens of thousands objects (Zclass that are DTMLDocument on steroids) on some twenty properties each day, while the absolute number of objects cataloged keeps growing (think at content management for a big portal, where each day lots of content are added and modified and all the old content remains as a searchable archive and as material to recycle in the future). This seems for some aspects a task similar to what Erik Enge impacted couple a weeks ago. We first derived from CatalogAware, then switched to manage ourselves the cataloging - uncataloging - recataloging. The ZODB still bloat at a too much fast pace. ***Maybe there's something obvious we missed***, but when you have some 4thousands object in the catalog, if you add and catalog one more object the ZODB grows circa a couple of megabyte (while the object is some 1 k of text, and some twelve boolean and datetime and strings properties). If we pack the ZODB, Data.fs returns to an almost normal size (so the bloat are made by the transactions as tranalyzer.py confirms). Any hints on how to manage something like? We use both textindexes, fieldindexes, and keywordsindexes (textindex on string properties, fieldindexes on boolean and datetime, keywordindex on strings). Maybe one kind of indexes is to be avoided? Erik, any toughts? We are almost decided to switch to berkeleydb storage (the Minimal one) to get rid of the bloating, we are testing with it, but it seems to be discontinued because of a lack of requests. Any light on it? Is it production grade? Giovanni, I experienced similar problems trying to catalog ·~20 objects with ~500 MB text. Using CatalogAware objects will indeed lead to a really fat data base, and using the find objects for a ZCatalog requires considerable resources. A text index (more precise: the class UnTextIndex) works, as far as I understood it, this way: 1. The method UnTextIndex.index_object splits the text into single words, using the method [Globbing]Lexicon.Splitter. 2. UnTextIndex.index_object looks up the wordID (an integer) of each word in the lexicon. If a word is not yet listed in the lexicon, it is added to the lexicon. 3. All wordIDs are inserted into self._index, which maps wordIDs to the list of documents containing this word. 4. The unindex BTree , which maps the documentIds to the the list of all words appearing in an document is updated. If you are adding only one CatalogAware object during a transaction, this is quite expensive: Even if the indexed object contains only one new word, the entire lexicon needs to be updated. In my tests with the 20 objects (containing ordinary German texts) the lexicon contained ~ 1 million words. (BTW, I had not had a very close look into the contents of the lexicon, so I don't know yet exactly, why it is so large. But I noticed quite many entries like 38-jährige, 42-jährige (NN-year-old) entries. So a configurable splitter method might help quite much to reduce the size of the lexicon.) Hence, the above mentioned step 2 alone can result in a really bloated data base. A solution might be a kind of lazy catalog awareness: Instead of mangling a new object through one or more catalogs when it is created, this object could be added to a list of objects to be cataloged later. This way, the transaction to insert a new object would become much cheaper. I'm working on this, but right now it is quite messy. (I'm new to Python and Zope, and hence I'm stumbling over a few, hmmm, trip-wires...) But even using such a lazy catalog awareness, you might get into trouble. Using the ZCatalog's find objects function, I hit the limits of my Linux box: 640 MB RAM were not enough... As I see it, the main problem is that UnTextIndex.index_object tries to do all work at once: Updating the lexicon _and_ self._index _and_ self._unindex So I tried to separate these tasks by writing the data to be stored in self._index (wordId, documentId, score) into a pipe. This pipe is connected to sort(1). After all objects have been scanned, the pipe is closed, the sorted results are read back and self._index is updated. This way, Zope needed only, uuhh, somewhat aroud 200 or 300 MB RAM. A few weeks ago, I've posted this (admittedly not fully cooked) patch to this list, but did not get yet any response. Abel ___ 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 )
