Re: [Zope-dev] Re: [Zope-dev]ZPL and GPL licensing issues

2001-06-25 Thread Gregor Hoffleit

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

2001-06-25 Thread R. David Murray

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?)

2001-06-25 Thread Chris Withers

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?)

2001-06-25 Thread abel deuring

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

2001-06-25 Thread Coi Giovanni

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?)

2001-06-25 Thread Chris McDonough

 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

2001-06-25 Thread R.

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

2001-06-25 Thread Jerome Alet

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

2001-06-25 Thread Lalo Martins

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?)

2001-06-25 Thread Erik Enge

(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

2001-06-25 Thread Erik Enge

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

2001-06-25 Thread Erik Enge

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?)

2001-06-25 Thread Chris McDonough

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

2001-06-25 Thread Joachim Werner

 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

2001-06-25 Thread Richard Jones

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

2001-06-25 Thread Stephan Richter


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

2001-06-25 Thread Anthony Baxter


 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

2001-06-25 Thread Anthony Baxter


 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

2001-06-25 Thread Lalo Martins

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

2001-06-25 Thread Dieter Maurer

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?)

2001-06-25 Thread Giovanni Maruzzelli

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?)

2001-06-25 Thread abel deuring

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 )



Re: [Zope-dev] Zcatalog bloat problem (berkeleydb is a solution?)

2001-06-25 Thread Chris McDonough

 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 .

 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.
:-(

- 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 )