Re: [Zope-dev] getattr for non-Folderish item

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

Re: [Zope-dev] RFC: How-To on subclassing Shared.DC.Scripts.Script.Script

[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] ZPL and GPL

[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] ZPL and GPL

[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] RFC: How-To on subclassing Shared.DC.Scripts.Script.Script

[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

[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] ZClass not in a Product

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

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

[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] ZPL and GPL

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

Re: [Zope-dev] ZPL and GPL

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

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

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

[Zope-dev] RFC: How-To on subclassing Shared.DC.Scripts.Script.Script

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

Re: [Zope-dev] ZPL and GPL

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

Re: [Zope-dev] ZPL and GPL

[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] Re: [Zope-dev] Zcatalog bloat problem (berkeleydb is a solution?)

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

[Zope-dev] DCOracle2 and SP problem

[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-dev] Zcatalog bloat problem (berkeleydb is a solution?)

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

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

[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] Speed up the learning curve

[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-dev] MountedFileStorage : absolute_path return / instead of mounted poing

[Hannu Krosing]

Sin Hang Kin wrote:
> 
> I was playing with MountedFileStorage, and found that the absolute_path used
> in breadcrumb is returning the / instead of the mounted point. Can somebody
> give it a patch?
> 
> Moreover, Can I mounted a Bsddbstorage with it?
> 

Thats what Chris McDonough <[EMAIL PROTECTED]> answered to my similar
query:

> 
> A small amount of info is here:
> 
> There's some information about mounting here: 
> http://www.zope.org/Members/randy/ZEO-Sessions
> 
> 
> 
> Hannu Krosing wrote:
> > 
> > Hi
> > 
> > Where can I find examples of Mountable Storages
> > 
> > I hope this is the right mailing list to ask this.
> > 
> > The search at Zope org gave almost nothing on the subject.
> > 


With a small amount of tweaking I got plain Zope to mount both Bsddb
storage and 
DemoStorage (i did not try the mount anything in ZEO )

The main trick is to create the two required objects. Fore DemoStorage
you have 
to create them each time as DemoStorage is non-persistent ;)



Hannu

___
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: ZPL and GPL

[Fred Wilson Horch]

Hi Shane,

You wrote:
> According to management, there's a zope-license list somewhere and we
> expect to move to a GPL compatible license.

Good news!  When you get a chance, can you post the name of the
zope-license list to zope-dev?  I think there a few developers who are
interested in licensing issues.

> 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."
 
I'm glad to hear this.  IMHO, GPL would be an even better off-the-shelf
license than Apache.  The Free Software Foundation (who really care
about these sorts of things, and who do a lot of evangelizing for the
cause) analyzes the plethora of "open source" licenses at
http://www.gnu.org/philosophy/license-list.html.

The choice of license will make Digital Creation's business strategy
more transparent.  Choosing an Apache license instead of the GPL
establishes a different relationship with the development and user
community, with major implications for the long-term fate of Python and
Zope.

But in any case, I think that licensing Python and Zope under the same
off-the-shelf license is a good idea.
-- 
Fred Wilson Horch   mailto:[EMAIL PROTECTED]
Executive Director, EcoAccess   http://ecoaccess.org/
P.O. Box 2823, Durham, NC 27715-2823phone: 919.419-8567

___
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]

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

[Zope-dev] getattr for non-Folderish item

[Johnson, Michael (MIJOHNSO)]

When using getattr to obtain a dtml file, etc from a newly formed product, I
am able 
to get the appropriate Zope object and use it.  However, I am trying to
abstract my 
class, and when I do, the getattr() function does not work properly.

Here's some info:
1) it is not a folderish item
2) the abstract class does not have the need to be managed (ex. Add)
3). Originally I just inherited (for Class 2) from Acquisition.Implicit,
figured I could 
access a persistant member in ZODB, but not even sure if I know what
persistance is 
anymore even after reading some wonderful Tutorials

If this all sounds like jibberish, it is.. I'll explain by example

Class1
I can use getattr(self, item_id) and it returns item, I guess because the
product is 
actually managed by Zope.. Could someone shed more light on this?

I would like to say db_item = Class2(class2 constructors)
db_item.process_something(item_id, args)

Class2
def process_something(item_id, args)
item_to_process=getattr(?, item_id) ? tried self, does not find
item_to_process().whatever_the_function(args)

Please excuse my dismal attempts.



___
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] 2.4 b1 binary doesn't run on win2k

[[EMAIL PROTECTED]]

[EMAIL PROTECTED]  wrote:

> hello to all
>
> i posted this on zope this morning and it appears that i'm not the 
> only one with this problem, so i thought - give it a try at zope-dev:
>
> zope 2.4b1 doesnt start in manual mode from the cmd prompt - it exits 
> without any output
> its no problem with ports or other zopes, because in such a case it 
> would at least give  me a line feedback
>
> i tried with the included python.exe and with the one in my path 
> (activepython 2.1 build 210 from active state)
>
>
> i have installed various 2.3x versions parallel but this shouldnt make 
> a problem because till now there has never been a problem in manual mode
>
> i don't want to deinstall my other versions because i want to have a 
> 2.31 version on my production machine
>
>
> any suggestions ??
>
> thanks in advance - bernd
>
> ___
> 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 )


its me again [;-)]

zope runs on port 80 by default, seems that i missed this somewhere
so i set it to 8080 with the -w8080 flag

but now i get the following traceback:

D:\zope240b1>python z2.py -X -D -w8080
Traceback (most recent call last):
 File "z2.py", line 540, in ?
   import ZServer
 File "D:\ZOPE24~1\ZServer\__init__.py", line 87, in ?
   from medusa.test import max_sockets
 File "D:\ZOPE24~1\ZServer\medusa\test\max_sockets.py", line 2, in
   import socket
 File "D:\ZOPE24~1\bin\lib\socket.py", line 47, in ?
   __all__.extend(os._get_exports_list(_socket))
AttributeError: 'os' module has no attribute '_get_exports_list'

?

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

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

[Zope-dev] dtml method question

[Simon Michael]

Context: I am within a python expression in a DTML Method being called
on a ZWiki Page, eg via http://zwiki.org/FrontPage/method.

"this" seems to refer to the method.
How do I get a reference to the zwiki page ?

Tips greatly appreciated.
-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] 2.4 b1 binary doesn't run on win2k

[[EMAIL PROTECTED]]

hello to all

i posted this on zope this morning and it appears that i'm not the only 
one with this problem, so i thought - give it a try at zope-dev:

zope 2.4b1 doesnt start in manual mode from the cmd prompt - it exits 
without any output
its no problem with ports or other zopes, because in such a case it 
would at least give  me a line feedback

i tried with the included python.exe and with the one in my path 
(activepython 2.1 build 210 from active state)


i have installed various 2.3x versions parallel but this shouldnt make a 
problem because till now there has never been a problem in manual mode

i don't want to deinstall my other versions because i want to have a 
2.31 version on my production machine


any suggestions ??

thanks in advance - bernd

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

[Barry A. Warsaw]

> "GM" == Giovanni Maruzzelli <[EMAIL PROTECTED]> writes:

GM> We are almost decided to switch to berkeleydb storage (the
GM> Minimal one) to get rid of the bloating, we are testing with
GM> it, but it seems to be discontinued because of a lack of
GM> requests.

GM> Any light on it? Is it production grade?

There are currently two versions of non-undo, non-versioning Berkeley
based storages.  One is called Packless.py and one is called
Minimal.py.   Packless was written first, and is truly packless; it
uses reference counting to get rid of unused objects.  Minimal isn't
quite packless yet, since the reference counting hasn't been added.
OTOH, Minimal shares much as much implementation as possible with
Full, so it shares e.g. the more robust backing commit log file
stuff.

A goal, although not likely for 1.0 is to merge the best features of
Minimal and Packless into a single storage.  I don't think it's a lot
of work to do this, but Jim hasn't pressed this has as having a very
high priority.

-Barry

___
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]

On Mon, 25 Jun 2001, 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."

Why not use the new Python's one instead ?

just to know...

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] ZPL and GPL

[Shane Hathaway]

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."

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 )

Re: [Zope-dev] Re: Problems with Transparent Folder and Zope 2.3.3

[Shane Hathaway]

On Monday 25 June 2001 04:47, Chris Withers wrote:
> Shane Hathaway wrote:
> > Again, it doesn't allow layers from outside the portal_skins tool
> > because of security considerations, not performance considerations.
>
> Erm... I know I'm being dense, but coudl you explain these again?

That's alright.  Skins are chosen before authentication.  If we allowed 
skins outside the skins tool, people would expect security to apply (so 
that, for example, only certain users get to use certain skins).  But 
since skins are chosen before authentication, you can either ignore 
security or only allow anonymously accessible folders.

We chose to avoid the need for security checks in skin paths, since the 
other route would have yielded unexpected behavior (only anonymously 
accessible folders) and would have been slower.

BTW skins can't be chosen after authentication in the general sense so 
don't ask. :-)  You could make your own skins tool that chooses the path 
after auth, but either ZPublisher or your user folder would have to be 
patched to make it happen, but that's not an option for a release version 
of CMF.

All of this may change in future versions.

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] Zcatalog bloat problem (berkeleydb is a solution?)

[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] Re: [Zope-dev]ZPL and GPL licensing issues

[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] Re: [Zope-dev]ZPL and GPL licensing issues

[ender]

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?

kapil




___
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

[Rene Pijlman]

[Clear error message when method in Python-based product has no
doc string]
> Doesn't it do precisely this when you run Zope in debug mode?

I don't know, you may be right. I'll look into that. Thanks.

But still, catching errors is not the same as debugging. I think
Zope will be user friendlier when it gives a better error
message directly.

Coincidentally, I just received this Alertbox:
"Established wisdom holds that good error messages are polite,
precise, and constructive. The Web brings a few new guidelines:
Make error messages clearly visible, reduce the work required to
fix the problem, and educate users along the way."
http://www.useit.com/alertbox/20010624.html

This is good reading for zope-dev's :-)

It contains an interesting idea with respect to the learning
curve:

"Users read system documentation only when they are in trouble
(that's the Second Law). They are particularly attentive when
they want to recover from an error. Given this, you can use
error messages as an educational resource to impart a small
amount of knowledge to users. Of course, error messages should
be brief and to the point, as should all Web content. However,
error messages can still teach users a bit about how the system
works and give them information they need to use it better. To
further that end, the Web's underlying technology makes another
guideline possible:

Hypertext links can be used to connect a concise error message
to a page with additional background material or an explanation
of the problem. (Don't overdo this, though.) "

He's right. It really would have helped if the Zope error
message linked to a page explaining the error message, listing
possible causes and advising to run Zope in debug mode.

Would it be possible to link Zope error messages to a website
(with a unique page for every error)? Maintaining the
documentation per error on this website could very well be a
community effort of course.

Regards,
Rene Pijlman


___
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: Problems with Transparent Folder and Zope 2.3.3

[Chris Withers]

Shane Hathaway wrote:
> 
> Well, if the getattr function in TransparentFolderPatch were in C, I
> think it would be fast enough.

Cool :-)

> Again, it doesn't allow layers from outside the portal_skins tool because
> of security considerations, not performance considerations.

Erm... I know I'm being dense, but coudl you explain these again?

cheers,

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 )