RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors

[Jean-Francois . Doyon]

Juan David,

Indeed, thanks for the input, I've ruled out new_publish as the cause as
well ...

Right now, I'm at the stage where I severely suspect it's got something to
do
with i18n support or translation somehow, but don't know where exactly yet.

If I remove the message_catalog, the problem goes away.

If I remove the TranslationService instance, the problem goes away. Do you
use this? Does anybody know of alternatives to the
TranslationService+Localizer
combo to enable i18n in ZPT's on Zope 2?

If I keep the above two, but delete my custom Localizer instances, the
problem persists.

I was trying to find an alternative message_catalog to use, but couldn't
find one (CMFLocalizer is based on yours).

So I'm going to try and narrow the field some more.  I *quickly* looked
the message_catalog and TranslationService code, and nothing jumped out.
I have to also look at the ZPT engine itself, maybe it's i18n
support is the cause of the problem.

I'll run further tests ...

Thanks,
J.F.

-Original Message-
From: "J. David Ibáñez" [mailto:[EMAIL PROTECTED]
Sent: May 21, 2004 8:17 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage
caused by errors



The problem I have with one of my sites seems to have a different cause, 
as it
does not show up when errors occur, but when requests are succesful.

So far I haven't been able to reproduce the problem.

You can try to modify "new_publish" to catch exceptions:

def new_publish(request, module_name, after_list, debug=0):
id = get_ident()
Publish._requests[id] = request
try:
x = Publish.old_publish(request, module_name, after_list, debug)
except:
del Publish._requests[id]
raise
else:
try:
del Publish._requests[id]
except KeyError:
...


Though it is unlikely the leak to be there.




[EMAIL PROTECTED] wrote:

>Indeed, I was hoping the ref in the dictionary there was getting in the way
>when old_publish was raising an exception, but I tried using a
>weakref.proxy()
>instead and that didn't help.
>
>I managed to test without Localizer (It dawned on me that since I'm looking
>at errors, it really doesn't matter if I don't have Localizer installed
>since
>not having it will generate errors, which is what I want!) ... And the
>problem
>diappeared ...
>
>So it's definitely Localizer, but it's not the Globals() request patch ...
>Or
>at least not the act of patching it itself, that causes the problem.
>
>*sigh*
>J.F.
>
>-Original Message-
>From: Dieter Maurer [mailto:[EMAIL PROTECTED]
>Sent: May 20, 2004 2:58 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage
>caused by errors
>
>
>[EMAIL PROTECTED] wrote at 2004-5-20 09:58 -0400:
>  
>
>>...
>>def new_publish(request, module_name, after_list, debug=0): 
>>   id = get_ident() 
>>   print "Localizer got thread id: " + str(id)
>>   Publish._requests[id] = request 
>>   print "Request dict is now: " + str(Publish._requests)   
>>   x = Publish.old_publish(request, module_name, after_list, debug) 
>>   try:
>>   del Publish._requests[id]
>>   except KeyError:
>>...
>>
>>
>
>This code cannot leak requests in large numbers (though it may
>leak a few requests for some time).
>
>Reason: Zope does not normally create new threads. This implies
>that thread_ids are reused and thereby old requests flushed from
>the dict.
>
>  
>


-- 
J. David Ibáñez
Founder and CTO of Itaapy 
9 rue Darwin, 75018 Paris
Tel +33 (0)1 42 23 67 45 / Fax +33 (0)1 53 28 27 88 

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors

[Jean-Francois . Doyon]

Indeed, I was hoping the ref in the dictionary there was getting in the way
when old_publish was raising an exception, but I tried using a
weakref.proxy()
instead and that didn't help.

I managed to test without Localizer (It dawned on me that since I'm looking
at errors, it really doesn't matter if I don't have Localizer installed
since
not having it will generate errors, which is what I want!) ... And the
problem
diappeared ...

So it's definitely Localizer, but it's not the Globals() request patch ...
Or
at least not the act of patching it itself, that causes the problem.

*sigh*
J.F.

-Original Message-
From: Dieter Maurer [mailto:[EMAIL PROTECTED]
Sent: May 20, 2004 2:58 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage
caused by errors


[EMAIL PROTECTED] wrote at 2004-5-20 09:58 -0400:
> ...
>def new_publish(request, module_name, after_list, debug=0): 
>id = get_ident() 
>print "Localizer got thread id: " + str(id)
>Publish._requests[id] = request 
>print "Request dict is now: " + str(Publish._requests)   
>x = Publish.old_publish(request, module_name, after_list, debug) 
>try:
>del Publish._requests[id]
>except KeyError:
> ...

This code cannot leak requests in large numbers (though it may
leak a few requests for some time).

Reason: Zope does not normally create new threads. This implies
that thread_ids are reused and thereby old requests flushed from
the dict.

-- 
Dieter

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors

[Jean-Francois . Doyon]

Juan David,

OK, 1.1.0a3 indeed suffers from the same problem, I'm going to take a closer
look the the publishing mechanism to see if I can find anything relevant.

Thanks,
J.F.

-Original Message-
From: "J. David Ibáñez" [mailto:[EMAIL PROTECTED]
Sent: May 20, 2004 10:17 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage
caused by errors



The "a" in 1.1.0a3 means "alpha". If the problem is in Localizer
1.0.1 I think it will be in 1.1.0a3 too.

Yes, I have a site with a similar behaviour, unfortunately today
the network connection is too slooow, so I can't test that site. I'm
going to do some local tests, though.

Yes, the problem might be the fact that "new_publish" does not
catch exceptions to remove the request from the dictionary.



[EMAIL PROTECTED] wrote:

>Juan David,
>
>I'm using 1.0.1 ... I'm just abotu to try and test with 1.1.0a3 ...
>
>BTW, does that mean it's alpha software or something? is 1.1.0 stable?
>
>If the problem comes from Localizer I suspect this patch might be the
cause:
>
>def new_publish(request, module_name, after_list, debug=0): 
>id = get_ident() 
>print "Localizer got thread id: " + str(id)
>Publish._requests[id] = request 
>print "Request dict is now: " + str(Publish._requests)   
>x = Publish.old_publish(request, module_name, after_list, debug) 
>try:
>del Publish._requests[id]
>except KeyError:
># XXX 
># Some people has reported that sometimes a KeyError exception is
># raised in the previous line, I haven't been able to reproduce it.
># This try/except clause seems to work. I'd prefer to understand
># what is happening.
>LOG('Localizer', PROBLEM,
>"The thread number %s don't has a request object associated." %
>id)
>except:
>print "Localizer got an exception" 
> 
>return x 
>
>What happens if an exception occurs here:
>
>x = Publish.old_publish(request, module_name, after_list, debug) 
>
>??
>
>If some clean up code is supposed to occur it might be held back by the
fact
>that
>there's a reference to the request kept in the global dictionary ...
>At least that's my theory :)
>But then I'm mostly uneducated about the intricacies of exception handling
>at this
>level, though I've been forced to learn quickly :)
>
>I'd be curious to know at least if you can reproduce the leak by generating
>loads
>of errors on a Localizer enabled site?
>
>One option would also be to simply wrap it in a try:catch and see what
>happens there
>... But I noticed 1.1.0a3 uses a different model for wrapping the request,
>so that
>just might do the trick.
>
>Thanks for a very cool and useful product BTW.  This is combination with
the
>TranslationService is saving me loads of time.
>
>Cheers,
>J.F.
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Behalf Of "J. David Ibáñez"
>Sent: May 20, 2004 6:47 AM
>To: Tres Seaver
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by
>errors
>
>
>
>Localizer (1.0.1) dynamically patches Zope, it stores a dictionary in 
>the module
>"ZPublisher.Publish". The keys are integers, they are the values 
>returned by Python's
>"thread.get_ident". The values are "ZPublisher.HTTPRequest.HTTPRequest"
>instances, they are not acquisition wrappers.
>
>Jean-François, which Localizer version do you use? Just to be sure we 
>look at
>the same code.
>
>
>  
>


-- 
J. David Ibáñez
Founder and CTO of Itaapy 
9 rue Darwin, 75018 Paris
Tel +33 (0)1 42 23 67 45 / Fax +33 (0)1 53 28 27 88 

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors

[Jean-Francois . Doyon]

Juan David,

I'm using 1.0.1 ... I'm just abotu to try and test with 1.1.0a3 ...

BTW, does that mean it's alpha software or something? is 1.1.0 stable?

If the problem comes from Localizer I suspect this patch might be the cause:

def new_publish(request, module_name, after_list, debug=0): 
id = get_ident() 
print "Localizer got thread id: " + str(id)
Publish._requests[id] = request 
print "Request dict is now: " + str(Publish._requests)   
x = Publish.old_publish(request, module_name, after_list, debug) 
try:
del Publish._requests[id]
except KeyError:
# XXX 
# Some people has reported that sometimes a KeyError exception is
# raised in the previous line, I haven't been able to reproduce it.
# This try/except clause seems to work. I'd prefer to understand
# what is happening.
LOG('Localizer', PROBLEM,
"The thread number %s don't has a request object associated." %
id)
except:
print "Localizer got an exception" 
 
return x 

What happens if an exception occurs here:

x = Publish.old_publish(request, module_name, after_list, debug) 

??

If some clean up code is supposed to occur it might be held back by the fact
that
there's a reference to the request kept in the global dictionary ...
At least that's my theory :)
But then I'm mostly uneducated about the intricacies of exception handling
at this
level, though I've been forced to learn quickly :)

I'd be curious to know at least if you can reproduce the leak by generating
loads
of errors on a Localizer enabled site?

One option would also be to simply wrap it in a try:catch and see what
happens there
... But I noticed 1.1.0a3 uses a different model for wrapping the request,
so that
just might do the trick.

Thanks for a very cool and useful product BTW.  This is combination with the
TranslationService is saving me loads of time.

Cheers,
J.F.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of "J. David Ibáñez"
Sent: May 20, 2004 6:47 AM
To: Tres Seaver
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by
errors



Localizer (1.0.1) dynamically patches Zope, it stores a dictionary in 
the module
"ZPublisher.Publish". The keys are integers, they are the values 
returned by Python's
"thread.get_ident". The values are "ZPublisher.HTTPRequest.HTTPRequest"
instances, they are not acquisition wrappers.

Jean-François, which Localizer version do you use? Just to be sure we 
look at
the same code.


Tres Seaver wrote:

> [EMAIL PROTECTED] wrote:
>
>> Gents,
>>
>> In following to the discussions regarding the leakage zope.org and my 
>> site
>> suffer from, I've done some testing, and here's what I've found.
>>
>> First of all, the leak does seem to occur when errors occur.  Unlike 
>> what
>> Chris suggested, I still suffer from this leak even when I completely
>> remove standard_error_message.
>>
>> How I tested:
>>
>> I use JMeter, and a 99% identical box, dedicated for testing:
>>
>> - RH 7.3
>> - Python 2.3.3 compiled with ./configure and no options
>> - Zope 2.7 + a variety of products, both custom and well known (CMF,
>> Localizer, etc ...)
>>
>> I look at my error log on my main site to see the types of errors 
>> coming up
>> and note the URL/parameters.
>> Such errors include KeyErrors, a RecursionDepth error, a
>> Method-something-or-other error, and so on.
>>
>> I setup JMeter with multiple concurrent threads and run it.  Within 
>> minutes
>> I can see refcounts growing abnormally on the test server.
>>
>> I then shut everything down and minimize the caches.  The following 
>> are left
>> around that shouldn't be:
>>
>> Class  May 19, 2004 1:52 pm  May 19, 2004 2:26 pm  Delta  
>> Acquisition.ImplicitAcquirerWrapper  1025  1309  +284  
>> ZServer.HTTPResponse.ZServerHTTPResponse  150  247  +97  
>> ZPublisher.BaseRequest.RequestContainer  146  240  +94  
>> ZPublisher.HTTPRequest.HTTPRequest  172  262  +90
>>
>> Right now I've focused on finding out why the Requests are still around.
>>
>> Using the gc module, I've found that all leaked requests are being 
>> held by a
>> dictionary.  If I look at said dictionaries, this is what they might 
>> look
>> like:
>>
>> {'REQUEST': >
URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh

>>
>> _site/francais/mapsatoz>},
>>  {'REQUEST': >
URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh

>>
>> _site/francais/mapsatoz>},
>>  {'REQUEST': >
URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh

>>
>> _site/english/search/political>},
>>  {'REQUEST': >
URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh

>>
>> _site/english/search/political>},
>>  {'REQUEST': >
URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh

>>
>> _site/english/search/political

RE: [Zope-dev] Preliminary findings: Zope 2.7 leakage caused by e rrors

[Jean-Francois . Doyon]

Dieter,

Thanks yet again for all the valuable input.

I've started tracking down/running into the whole ExtensionClasses
instances/issues.

As you suggest, the dict is probably help by BaseRequest.RequestContainer,
which I've
seen grow in parallel to the HTTPRequest refcounts ... Which seems to make
sense.

And as you suggest, as I've been doing this, I've been thinking I'm really
looking forward to getting ri dof ExtensionClass, makes this kind of work
much easier.

The requests themselves look clean, but if they contain ExtensionClasses
based instances
gc wouldn't find them for the same reason.  I've gotten far enough to be
able to tell
there's a variety of them.  I suspect the instance the error occured ON is
what's leaked
(So if it's a CMFDocument, then that said Document ends up leaked).  I was
just getting
to this yesterday, hopefully I'll solve that today.

As Tres suggested, I'm going to go back to looking at Localizer ... It's the
likliest suspect
at this time.  It's just hard for to test since pretty much everything I
have depends on
i18n PT's, and in some cases I have gettext() calls in Python code.
Localizer "wraps"
the Publish.publish, and I'm thinking that when exceptions occur in there
Localizer
needs to be aware of it and react accordingly, which it doesn't right now.

The hunt goes on ...

Cheers,
J.F.

-Original Message-
From: Dieter Maurer [mailto:[EMAIL PROTECTED]
Sent: May 20, 2004 3:52 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [Zope-dev] Preliminary findings: Zope 2.7 leakage caused by
errors


[EMAIL PROTECTED] wrote at 2004-5-19 14:44 -0400:
> ...
>Right now I've focused on finding out why the Requests are still around.
>
>Using the gc module, I've found that all leaked requests are being held by
a
>dictionary.  If I look at said dictionaries, this is what they might look
>like:
>
>{'REQUEST': URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_v
h
>_site/francais/mapsatoz>},
> {'REQUEST': URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_v
h
>_site/francais/mapsatoz>},

These dictionaries look like the "instance dict"s of
the "ZPublisher.BaseRequest.RequestContainer"s.

When you have any cycle involving an AcquisitionWrapper,
then its reference to the "RequestContainer" will keep this alive
together with its instance dict.

You may analyse the content of your requests.
Do they contain acquisition wrapped objects (or other objects
with (maybe indirect) references to this dict)?

If not, "REQUEST" does not seem to be the root of your cycles
but rather a side effect.


More important notes:

  *  When you see "AcquisitionWrapper"s in the reference information
 in "Control_Panel --> Debug Information", then
 there *must* also be other prominent ExtensionClass'es --
 the "aq_base" of these wrappers.

 These classes may provide a valuable clue towards the cause
 of the cycles -- of global variables (by the way).

  *  The reference information in "Control_Panel" covers only
 instance objects but not elementary Python data types.

 Thus, when cycles are caused by elementary Python objects,
 we may not directly see them in the list.

 GC's "DEBUG_LEAK" may provide some information.

  *  The leaks may not be caused by cycles at all (though it is
 the most likely cause) but could result from a global
 cache containing references to acquisition wrapped objects.

 Such a cache should never exist -- global variables and
 class attributes must never directly or indirectly reference
 persistent objects -- as this results in nasty persistency bugs.

 Nevertheless, sometimes software is buggy. I noticed
 such a cache in Archetypes 1.3a2 (fixed in newer versions).


>Said dictionary does not seem to be referred to by anything, at least not
>anything the gc module can find (gc.get_referrers()).

That's probably because "RequestContainer" is an ExtensionClass
and ExtensionClasses are not yet (only from Zope 2.8 on) GC aware.

> ...
>Also I
>understand zope.org suffers from this? :)

Leaks can have innumerable causes. It is by no means clear
that your leak and the one on Zope.org has the same cause.

>Based on this information also, I have no reason to believe this is caused
>by product code ... I have to guess it's a Zope bug?

I do not observe leaks in my Zope installation -- even when
I make an error stress test.

This does not mean it could not be a Zope bug --
but it implies that such a bug does not surface regularly, at most
under special conditions.

>In some ways this is motivating me to reduce the number of errors that
could
>occur, but because ALL errors seems to cause the problem, I ultimately have
>no control over it and under certain circumstances I suffer heavily from
>this.  404's alone probably cause this (I'm plannign to test that
>explicitely as well).

It does not here

Something is s

[Zope-dev] Preliminary findings: Zope 2.7 leakage caused by errors

[Jean-Francois . Doyon]

Gents,

In following to the discussions regarding the leakage zope.org and my site
suffer from, I've done some testing, and here's what I've found.

First of all, the leak does seem to occur when errors occur.  Unlike what
Chris suggested, I still suffer from this leak even when I completely
remove standard_error_message.

How I tested:

I use JMeter, and a 99% identical box, dedicated for testing:

- RH 7.3
- Python 2.3.3 compiled with ./configure and no options
- Zope 2.7 + a variety of products, both custom and well known (CMF,
Localizer, etc ...)

I look at my error log on my main site to see the types of errors coming up
and note the URL/parameters.
Such errors include KeyErrors, a RecursionDepth error, a
Method-something-or-other error, and so on.

I setup JMeter with multiple concurrent threads and run it.  Within minutes
I can see refcounts growing abnormally on the test server.

I then shut everything down and minimize the caches.  The following are left
around that shouldn't be:

Class  May 19, 2004 1:52 pm  May 19, 2004 2:26 pm  Delta  
Acquisition.ImplicitAcquirerWrapper  1025  1309  +284  
ZServer.HTTPResponse.ZServerHTTPResponse  150  247  +97  
ZPublisher.BaseRequest.RequestContainer  146  240  +94  
ZPublisher.HTTPRequest.HTTPRequest  172  262  +90

Right now I've focused on finding out why the Requests are still around.

Using the gc module, I've found that all leaked requests are being held by a
dictionary.  If I look at said dictionaries, this is what they might look
like:

{'REQUEST': },
 {'REQUEST': },
 {'REQUEST': },
 {'REQUEST': },
 {'REQUEST': },
 {'REQUEST': },
 {'REQUEST': },
 {3075: ,
  4100: ,
  5125: ,
  6150: ,
  7175: },
 {'REQUEST': },
 {'REQUEST': }

NOTE: I had to hack the __repr__ of HTTPRequest not to use self['URL'] since
it seems that attribute is unavailable in a closed request.  I use PATH_INFO
instead.

Most of the time I get the dictionary with the 'REQUEST' key.  Those
dictionaries with int's as keys are ones generated by the ExternalMethod I
use to run the code to debug ... So even errors raised while trying to debug
this leaks a dictionary that holds on to the request(s).

Said dictionary does not seem to be referred to by anything, at least not
anything the gc module can find (gc.get_referrers()).  One possible
situation is that said dictionary is actually part of the HTTPRequest, and
we have a cyclic reference problem.  I don't think so however, I've looked
at the HTTPRequest instances, and they have nothing in them other than
strings, lists, basic dict's and an HTTPResponse instance.  I'll take
another look to be sure.

Next step is too look at the Wrappers and see what they're all about and
what's holding them there.

I'm hoping this information might give a clue to someone who knows Zope
error handling better than I as to what might be the problem here ... Also I
understand zope.org suffers from this? :)

Based on this information also, I have no reason to believe this is caused
by product code ... I have to guess it's a Zope bug?

In some ways this is motivating me to reduce the number of errors that could
occur, but because ALL errors seems to cause the problem, I ultimately have
no control over it and under certain circumstances I suffer heavily from
this.  404's alone probably cause this (I'm plannign to test that
explicitely as well).

Thoughts, suggestions, comments welcome ...

Jean-François Doyon
Internet Service Development and Systems Support / Spécialiste de
dèveloppements internet et soutien technique
Canada Centre for Remote Sensing / Centre Canadien de télédétection
Natural Resources Canada / Ressources naturelles Canada
http://atlas.gc.ca
Tel./Tél. : (613) 992-4902
Fax: (613) 947-2410


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: [Zope-dev] How should an ideal Zope IDE look like?

[Jean-Francois . Doyon]

Well, I suspect the interest in this type of tool might be big enough
to allow for the open Source model to apply in an efficient manner ?

Depends on the skills required to bring it to life.

I've started using Eclipse lately, and I just love it, I've combined
PyDT/PyDEV + Subclipse + XMLBuddy and I have a decent tool for working
on my products and skins.

At home, I have a similar setup for working with Python/C, and it's
fantastic,
I'm far more productive with it.

Some people might take offense to using a Java tool to do the job, but it
seems
to me like a potentially excellent foundation.  Apparently Jython can be
integrated into it ...

I've been meaning to learn Java, maybe this would motivate me ? :P

As for Zope IDE vs. CMS IDE ... The line (to me anyways) is blurry.  Also,
given current projects, I'd focus on Zope 3, which with it's component
architecture makes things infinitely flexible, and therefore the line
between Zope and "CMS" is not easily distinguishable.

Ideally a full featured IDE would be component architecure aware and be able
to discover and leverage it (Which interfaces do you have ? Which components
?
How do I display this to the user ? Use that for code completion, Zope aware
debugger somehow, etc ...)

Maybe the ZMI functionality should be abstracted into a web service or
something
similar so that the ZMI is no longer purely restricted to a web interface?
(Maybe
it already isn't, admitedly, I don't know ...)

Anyways, admitedly all this is above my skill level at this time, but I
think the
idea has value ... If this were a reasonably priced commercial tool, I
probably would
buy it mind you.  Spending say a few hundred dollars to save hours and hours
of work
is common sense.  though a tool like that would be years away even someone
started now!

J.F.


-Original Message-
From: Chris Withers [mailto:[EMAIL PROTECTED]
Sent: May 6, 2004 3:51 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [Zope-dev] How should an ideal Zope IDE look like?


[EMAIL PROTECTED] wrote:

> More important is the second point:  Having such a tool would bring a
> HUGE amount of value added to Zope. Mega, super huge.

Sounds like the opportunity for a commercial tool.

It's not NEEDED, but it makes life a LOT easier, and so would give any
company 
with it competitive advantage without detracting at all from people who
don't 
use it...

> My main concern would be it's adaptibility to custom content types. If I
> have my own Geospatial-ish content type, how would the IDE handle it ?
> How would I go about making it handle it ? etc ...

That's the tough one ;-) BTW, I thought we were talking about a Zope IDE,
not an 
  IDE for a CMS built on top of Zope...

> Basically, yo me this should be a core feature of Zope, not an add-on.

Indeed. But having it as a core feature forces it to be open source, and
hence 
run on open source budgets and timescales.

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: [Zope-dev] How should an ideal Zope IDE look like?

[Jean-Francois . Doyon]

I agree with Andre.

The feature list is ambitious, but complete.  That's pretty much what
I was about to write myself, but he beat me to it :)

More important is the second point:  Having such a tool would bring a
HUGE amount of value added to Zope. Mega, super huge.

In fact I was once presented with an OO CMS much like Zope, but commercial,
where the IDE/Management interface was much like this ... That alone
was worh the 50K price tag ... Want to load a document ? Click -> Drag ->
Done.
That simple.

My main concern would be it's adaptibility to custom content types. If I
have my own Geospatial-ish content type, how would the IDE handle it ?
How would I go about making it handle it ? etc ...

In some respects I thnk such a project would be best "hosted" with Zope
itself, since to make it work really well you may need to do work
real close to the core of Zope.  Also, as mentionned given the immense
value added to the product, I'm thinking ZC would benefit greatly from
it and should maybe be involved ?

Basically, yo me this should be a core feature of Zope, not an add-on.

J.F.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Andre Meyer
Sent: April 24, 2004 5:24 PM
To: Aleks Totic
Cc: Martin Kretschmar; [EMAIL PROTECTED]
Subject: Re: [Zope-dev] How should an ideal Zope IDE look like?


It was not my expectation that you would go and implement all of this ;-)

Of course, this is a lot of work, but much has been done by others, 
already. The wish list was intended as ideas for those capable and 
willing to contribute. The value of good tools for any technology cannot 
be underestimated.

kind regards
Andre


Aleks Totic wrote:

> Nice wishlist. About 3-4 man years worth of coding, 2 min is my guess.
>
> My goal is not quite so ambitious. I wanted to learn Eclipse well. I 
> was always jelaous of Emacs guys that could whip up a mode for their 
> favorite lanuguage. Implementing a Python IDE sounded like a good 
> starter project. By IDE, I mean something with a debugger.
>
> In the next release (by the end of next month) I'll have some 
> hyperlinking (function/classdefs withing the same file, and on 
> imports), maybe some code completion (that's up to Dana), and a decent 
> debugger (multithreaded).
>
> After that, I am not sure. My goal for pydev is for it to be good 
> enough for small-size projects, and we'll almost be there. The larger 
> projects requirements (unit tests/UML editor/module awareness) are not 
> that exciting as a hobby.
>
> Aleks
>
> Andre Meyer wrote:
>
>> So, I give it a try and submit a "wish list" for an ideal IDE for 
>> Python/Zope.
>>
>> Maybe some words about the IDEs I have been working with, so you can 
>> track where the features I wish to have come from: I used 
>> CodeWarrior, NetBeans, jEdit for both Java and Python/Zope, Boa 
>> Constructor and Eclipse with several plugins (like Omondo UML plugin, 
>> TruStudio and PyDev).
>>
>> And here comes the list of features:
>>
>> - Syntax coloring (standard everywhere) for python and 
>> zpt/xml/html/css code.
>>
>> - Commenting/uncommenting code (any hope Python will ever offer 
>> multi-line comments?).
>>
>> - Auto-completion for python and zpt/xml/html/css, incl. parameter 
>> editing. One should be able to specify the path to modules: for 
>> example I have a Python installation and a Zope installation with 
>> Python offering different modules.
>>
>> - Show declaration: jump to definition of classes/instances elsewhere 
>> in the code using a context menu.
>>
>> - Refactoring: actions, such as renaming a class, method or module 
>> and modify all references in the rest of the code; move classes and 
>> methods up or down in the class hierarchy. Eclipse supports this for 
>> Java and it saves a LOT of time,
>>
>> - Unit tests with reporting.
>>
>> - Folding: show/hide parts of the source code (like in jEdit).
>>
>> - Split windows.
>>
>> - Project management.
>>
>> - CVS/Subversion integration.
>>
>> - Search/replace, incl. regex in open files, project,
>>
>> - Compare and edit files/folders (diff, meld).
>>
>> - Drag&drop editing.
>>
>> - Multi-threaded debugging.
>>
>> - Outline: display classes, methods, attributes of a source file.
>>
>> - Class/method popup.
>>
>> - Bookmarks.
>>
>> - Class browser: multi-part window for browsing and editing classes 
>> and their methods and attributes. Similar to the NeXTstep file 
>> browser and the Java Browser perspective in Eclipse.
>>
>> - UML editor (incl. code generation and reverse engineering). Eclipse 
>> has several UML plugins and offers a language-independent modelling 
>> framework (EMF) that supports code generation. This could be adapted 
>> for Python.
>>
>> - Design patterns, templates: not found anywhere, yet, but might be 
>> an interesting feature, especially for Zope development, where we 
>> have a lot of recipes that need to be applied often.
>>
>> - Pydoc integration: show the docs simultaneously with the code.
>>
>> - Z

RE: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition

[Jean-Francois . Doyon]

I know I'm new here, but I think this may work to my benefit in this case
...

+1 on everything Jim just said!

Unlike some others it seems, I look at Zope almost uniquely as "framework"
for
building web applications. An API or SDK if you will.  As such, I think it's
internal software desing and architecture has to be priority number one.
Otherwise anything you layer on top of it is doomed from the start.

To those people that just want an application server that works, such as
CPS or Plone, this should still be a very good thing. Having a much
higher quality base will mean better end-user usable products in the long
run ...

Personally, I'm fully expecting to do a full re-design of my code for Zope
3.
And that's fine, I like the idea.  Given the radical changes in design, I
would want to make sure my applications/products take full advantage of the
new
features.  I'm actually counting on several of them to do things like proper
multi-lingual support, workflow and publishing control.

I might actually NOT bother with migrating slowly through 2.8 and
2.9, that seems dangerous to me ... the potential for kludges and nasty work
arounds seems great. We'll have to see. Can't wait for ExtensionClass to go
though!!

In the mean time, I'll be trying to give back to the Zope community by
working on my Subversion storage idea :)

Thanks,
J.F.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jim Fulton
Sent: April 22, 2004 10:47 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition


Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 
>>> 2. Especially Andreas expressed his worries about the current release 
>>> policy in Zope 2 and its future regarding maintainance and support. I 
>>> have to say that I share some of his skepticism regarding Zope 2. I 
>>> personally have never fully understood ZC's reasons for the release 
>>> roadmap as it is. I might not see the big picture, but I know I would 
>>> have done it differently. I've always tried to make that clear in the 
>>> past.
>>
>>
>> I'm surprised to read this. Could you be more specific about your 
>> concerns?
> 
> 
> I should have said "the release roadmap as it WAS". I was very skeptical 
> about the original plans to make Zope3 backward compatible. I am still 
> very skeptical about the ability to add conversion scripts. They would 
> be incredibly tedious painful to write and I personally would rather 
> migrate code manually than trust a script. After all, the paradigms have 
> changed a lot.
> 
> I see it as realistic as Stephan. There is no sane migration to Zope3 
> than the one of refactoring code. Now, in order for that to happen, we 
> need the CA in Zope2, so people can start asap. My only criticism has 
> been and still is that the CA hasn't been introduced to Zope2 earlier. 
> Now, I know that a) the CA has been refactored a lot since its invention 
> (and IMO only for the good) and b) there was a lack of resources to do 
> that actual integration. That's why I've never declared anyone guilty 
> for it (which is why you may be surprised by this).
> 
> It sure would have been nice if Gary had shared his experience with 
> FrankenZope a little earlier. I remember Martijn being quite eager to 
> experiment with it, too. But that's the only constructive criticism I
have.

So your concerns are really about the Z2 to Z3 transition plan, not about
the Zope release process.

Before I get into the main topic of my response, I'll note that I'm a
good bit more optimistic about backward compatability than you are.
I just have an intuition that we'll be able to do much more than you
or Stephan expect. It's an intuition, not a promise. I can't prove it.
Only time will tell. :)

I know that lots of people are concerned by the uncertainlty about the
future transition.  This is a tough situation.  I made a number of
tradeoffs that put us in this situtaion.  I think they were the right
tradeoffs and I'd make them again.  But, as with any tradeoff, we've
had to balence positives and negatives.  Let me explain:

Zope 3 has always been a relatively small project.  Within Zope
Corporation, I'm the only one that has worked on Zope 3 full time
for any length of time.  As CTO, even my time on Zope 3 is
not truly full time, but it's closer than for anyone else at ZC.
Customer work (Zope 2), important community issues (like this thread,
or like the security issues we uncovered last fall) take precedent.

Other people working on Zope 3 have "day" jobs.  They have to go to
school or or do customer work (usually in Zope 2) to make a living.
(Of course, you know this Philipp. :)

I'm not complaining. This is reality and a reality we planned for.

I made two choices that were controversial:

1. I decided not to be encumbered by backward compatability.  This was
refactoring mercelessly" applied in the extreme. This had the result
that, except in a few areas, we did 

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Oh, a very good idea indeed! We'll have to look at that eventually.

The mechanism you describe is preferable, but it should be noted that
subversion properties are easily accessible using the clients.

So long as said properties are human readable/writable, that's also an
option.

The main issue for me (And many others I suppose), is the fact that every
single object type I use is either completely custom, or a monkey patched
version of a built-in type (Notably OFS.Image for instance).

So there would have to be a reliable serializer for "other" objects, which I
beleive you already have, so that's OK :)

What happens is you write a new serializer, notably write a custom
serializer for an object type you've already been using for a while, using
the "default" one ? (Presumably because you WANT to be able to access the
contents from other tools)

I think I noticed that somewhere in the .properties file there was a note of
the class used for serializing ... Is there a way for a serialized instance
to remember which serializer was used ? Or does everything break when I
change the definition of a serializer (Old instances can no longer be read)
?

J.F.

-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 14/04/2004 7:39 PM
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r
evis ion based storage for Zope ?)

On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote:

> Fact is if one wanted a client to interact with a svn repository that
stores
> zope objects, it would need to be fairly specifically designed for it
...
> How would a client (Say dreamweaver with a subversion plug-in) know
that
> when editing an image, the x and y size properties need to be updated
? What
> if someone monkey patches the image type to add some other
> property/attribute ?

I would say Ape is quite good at accepting data from non-Zope-aware
tools,
and I'd like to make it better.  The fact that Ape stores the image
dimensions separately from the image content is an implementation
decision
in the serializer.  You could instead tell the serializer to detect
image
dimensions when loading the object.  The detection is a relatively
inexpensive operation.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: [Zope-dev] More arguments for "z" (was Re: [Zope3-dev] Zope a nd zope)

[Jean-Francois . Doyon]

+1 from me !

I'm always in favor of less typing :P Besides, you make good points :)

J.F.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jim Fulton
Sent: April 14, 2004 3:54 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Zope-dev] More arguments for "z" (was Re: [Zope3-dev] Zope and
zope)


Jim Fulton wrote:
> Jim Fulton wrote:
> 
> ...
> 
>> Give the responses. I need to recast my question as a selection
>> among alternatives. But, before I do that, we will need to consider
>> alternatives a bit more.
> 
> 
> OK, here's another.
> 
> What about renaming the Zope 3 zope package to "z".
> 
> - It fits with the expansion of "Zope":
>   "Z Object Publishing Environment".
> 
> - It's short :)
> 
> - *At this time* (but after the move to svn), it's not too hard to make
>   a change like this for Zope 3. Backward compatibility is not a big
>   issue. This will change when X3.0 is released, which is why I'm
>   bothering to deal with this now.
> 
> - This was suggested a couple of years ago when coming up with the
>   Zope 3 package layout.
> 
> Examples (from the buddydemo example):
> 
>   import z.interface
>   from z.app import zapi
>   from z.app.event import publish
>   from z.app.event.objectevent import ObjectModifiedEvent

Other reasons I like "z":

- Less noise in imports

- Echos the "circle z"

- The packages in "z" can be used for more than just Zope

- Emphasizes the more "minimalist" nature of Zope 3 relative
   to Zope 2

- "z" is a component of "zope"

OK, I'm getting carried away. Sorry ;)

Jim

-- 
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

The property schema thing is a good point, though I'm not sure we could ever
do anything about it, not with the purpose to help "naive gui" clients work
better with the repository.

By nature the object structure (Class instance) is not fixed, so the
amount/name/data of properties could vary arbitrarily.  This is after all
the major benefit of an OODBMS.

Fact is if one wanted a client to interact with a svn repository that stores
zope objects, it would need to be fairly specifically designed for it ...
How would a client (Say dreamweaver with a subversion plug-in) know that
when editing an image, the x and y size properties need to be updated ? What
if someone monkey patches the image type to add some other
property/attribute ?

All we could hope to do is find a consistent and predictable way to handle
properties, so that clients would know at the very least how to read/write
them, but not necessarily know which one does what.  I suppose there's
possible ways around that actually, by providing some way to describe
properties and what they do and so on ... but that's beyond the scope of
what I'm trying to do I think ...

J.F.

-Original Message-
From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
Sent: April 14, 2004 6:51 AM
To: Shane Hathaway
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
r evis ion based storage for Zope ?)


On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote:
> On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote:
> 
> > Thanks for the extra tips, I'll check out those interfaces! I'm also
getting
> > up to speed on the whole mapper concept, where the work regarding
properties
> > handling seems to be ?
> 
> Ape supports both annotations and Zope properties.  Annotations are blocks
> of multi-line text, while Zope properties are less constrained.  On the
> filesystem, Ape stores many Zope properties together in a single
> annotation called "properties".  Other annotations include object
> classification, the remainder pickle (encoded in base 64), and security
> information.
> 
> What are the expectations and limits of Subversion properties?  If they
> are blocks of multi-line text, you can store the annotations as Subversion
> properties.  If not, we'll still need a .properties file.  (Note that 
> the name ".properties" is thus confusing.  Oops.)
> 

svn supports aribtrary property values. ie you can store binary
(remainder pickles, object classification, etc.) of arbitrary size on
them. there is some question of how well some naive gui client will do
when trying to list such properties, as there is currently no notion of
metaproperties/property schema beyond the property namespace for
introspection of a property.

-kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Well there you go, perfect :)

-Original Message-
From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
Sent: April 14, 2004 6:49 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
r evis ion based storage for Zope ?)


On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote:
> Hello,
> 
> Hmmm, well it's as stable as Ape and Subversion are respectively :)
> 
> I wouldn't call it stable no, it's something I did over the long week-end
we
> just had, and that's about it :)
> 
> Ape is at 0.8 and therefore becoming quite mature, I'd have to let others
> speak as to it stability however ...
> 
> Subversion is also probably quite stable (It just reached 1.0), though I
> don't know how heavily tested it's been in a long running process (Might
it
> have some memeory leaks ?) ...

the svn apache server model is a long running process and is fairly
stable on memory usage. the python bindings require doing some manual
memory management, but the pool api makes it easy to deallocate
arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has
been in production by myself and others for almost a year and runs with
a stable memory footprint.

-kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Shane,

As Kapil already mentionned, svn's support for properties is quite flexible,
so that doesn't worry me too much.

I would imagine and administrator having the flexibility of choosing how
objects get translateds to files might be handy.

My initial, uneducated thoughts on the topic were simplistic, but then I'm a
big K.I.S.S. fan: simply pickle the entire object back and forth as one
entity.  This means for each object, there is one file on the fs.  The
benefit is greater simplicity ... the downside is that you couldn't check
those files out of subversion and interact with them.  I also have to
imagine the former is faster ?

But if usnig the latter, then I'd think that in SVN there would be only 1
file, written by a specific mapper for a specific content type, say image.
the data written to the file is such that if checked out, the file "works",
so I can open it in photoshop or something.

I however, would simply put everything else in properties, if that makes
sense at all. Zope properties, security information, and so on.  1 porperty,
1 piece of data. No need for reading/writing multi-line text.

The only thing I'm not so sure about is this "remainder" ... Though if it
really is a base64 encoded string, there's no reason not to put that in a
property as well.

The benefits I see:

- The filesystem reflects the object structure, no extra files lying around.
- a more consistent way to setup mappers/gateways: there's "data", and
there's everything else. Have a common/defined/smart way of handling
"everything else".
- with the use of the properties related svn funtions, we better leverage
SVN's features.
- possibly better performance/simpler code by not needing the whole multiple
file management and read/write of text files.  Heck the whole
AnnotatedFileSystem, thing could be dropped/replaced with a
PropertyFileSystem implementation of some kind maybe ??

What do you think ?

J.F.

-Original Message-
From: Shane Hathaway [mailto:[EMAIL PROTECTED]
Sent: April 13, 2004 10:46 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
r evis ion based storage for Zope ?)


On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote:

> Thanks for the extra tips, I'll check out those interfaces! I'm also
getting
> up to speed on the whole mapper concept, where the work regarding
properties
> handling seems to be ?

Ape supports both annotations and Zope properties.  Annotations are blocks
of multi-line text, while Zope properties are less constrained.  On the
filesystem, Ape stores many Zope properties together in a single
annotation called "properties".  Other annotations include object
classification, the remainder pickle (encoded in base 64), and security
information.

What are the expectations and limits of Subversion properties?  If they
are blocks of multi-line text, you can store the annotations as Subversion
properties.  If not, we'll still need a .properties file.  (Note that 
the name ".properties" is thus confusing.  Oops.)

> As for the seperation of code ... I now have a "subversion" directory as
a
> sibbling to "fs" ... I had to edit a couple of files outside that
directory,
> but still the seperation is nicer.
> 
> eventually I'd have to make it into a product, is that doable ?

Why not add your code to Ape?  I think it would be easier for both of us
to maintain that way.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Kapil,

Right now, the svn transactions are entirely contained within a single
fileops operation: for example a "mkdir" connects to a transaction root,
performs the necessary operations, and commits, all in one shot.

Last night I took some more time to try and learn more about Ape's
functionning (Where events come from, which interfaces are used for what,
and TPC), so I'm starting to understand more ...

The more I learn, the more I think closer integration between SVN txn's and
Ape's TPC would be a good place to start before looking at adding features
like history support and so on: defining a model for what happens in svn for
each TPC related call (connect, vote, finish), and then as Shane had said,
look at IFSReader/IFSWriter (Which I now call
ISubversionReader/ISubversionWriter :P) to match.

Right now the fs implementation stores "script commands" that are cummulated
upon connect() (I think?), validated as best as possible upon vote() and run
upon finish().  I don't see why this couldn't be adapted to SVN txn's ...
connect() = start a txn, vote() = validation (what this entails needs to be
defined, could involve delta operations, revision number matching, etc ...
?), finish() = commit the svn txn.

Because we're within an svn transaction, there would be no need for fs style
script command accumulation however, which is nice.

J.F.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Kapil Thangavelu
Sent: April 14, 2004 6:59 AM
To: Shane Hathaway
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
revis ion based storage for Zope ?)


On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote:
> On Tue, 13 Apr 2004, Kapil Thangavelu wrote:
> 
> > since
> > objects modified in a version are in essence locked from participating
> > in other transactions, actions like modifying content in a version in a
> > cmf site amounts to locking the catalog from changes outside of the
> > version, which amounts to shutting down write activities to a cmf site.
> 
> This is only true of FileStorage.  Some other storage could implement ZODB
> versions with merging capability rather than locking.
> 

good point, just because hasn't been doesn't mean it can't ;-)

although i wonder if there is some hand waving in progress here that i
can't see. i guess my semantic notion of versions has been that of long
lived transactions, and is there a better means of thinking of them? how
do they play across with multiple mounted zodbs? what would something
like merge mean in the context of a catalog?

> > i'm also curious how you dealt with svn transactions as part of the ape
> > integration work to date.
> 
> The same way it tries to impose transactions on the filesystem: in the 
> vote phase, Ape looks for possible problems and aborts early if it detects

> anything that will cause the transaction to fail.  Obviously, this 
> provides no guarantee, but covers many cases.
> 

i was more curious how jean-francois was doing the svn ops in fileops,
as svn is fundamentally a transactional store (as opposed to the fs), ie
is there some record boundary notion of ape signalling the end of
serialization for an object set, or was each operation being conducted
in a separate svn transaction.

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Shane,

Thanks for the extra tips, I'll check out those interfaces! I'm also getting
up to speed on the whole mapper concept, where the work regarding properties
handling seems to be ?

I've done some reading, and I need to do some more, but I'll get there :)

As for the seperation of code ... I now have a "subversion" directory as  a
sibbling to "fs" ... I had to edit a couple of files outside that directory,
but still the seperation is nicer.

eventually I'd have to make it into a product, is that doable ?

J.F.

-Original Message-
From: Shane Hathaway
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: 13/04/2004 11:43 AM
Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
revis ion based storage for Zope ?)

On Mon, 12 Apr 2004 [EMAIL PROTECTED] wrote:

> This is step one because, as Shawn suggested (Thanks for the pointer,
that's
> what I needed!), this simply means that Zope uses SVN purely as a
> filesystem.
> 
> Because of subversion's nature, I want to look at 2 things beyond this
that
> traditional filesystems don't support:

To take this to the next level, you need to implement IFSReader and
IFSWriter instead of the more basic file operations interface.  See
Ape/lib/apelib/fs/interfaces.py.  In IFSReader/IFSWriter, you're a
little
closer to objects, and you work with OIDs instead of paths.  I expect
that
history and version support will require us to augment IFSReader or add
another interface.

> - Use zope's username for SVN logging.
> - History/Undo support: View past revisions of an object, and revert
to such
> a past revision.
> - Zope Version support: SVN is fully transactional and atomic, this
should
> allow for support of Zope versions (I think ?)

These seem doable.

> In the longer term, there's great opportunity for:
> 
> - "Built-in" conflict management and resolution: No more need for a
> "SafetyBelt" type approach.  Right now I haven't looked at this at
all.  I
> plan to implement smart merging where possible (It might work already
> actually, I just need to test it).  True conflicts (Where a merge
can't be
> accomplished withouth user interaction) would raise some sort of
conflict
> error.

This could be complicated, because after the merge you have to be 
sure Zope caches the merged state rather than either of the intermediate

states.  The idea has potential, though!

> - Editing Zope content objects through interaction with the svn
repository.
> I can checkout the repository, edit some objects, and chek them back
in,
> never interacting with Zope directly ... I've already tried this !
Works
> great for text based content types such as PageTemplates or DTML
Documents
> and so on ... I even did it with a JPG, though because the properties
hold
> width and height, you get some weird looking pictures :) The concept
is
> valid though.  There may someday be a way to leverage this
functionality
> better with a purpose built client of some sort.

Sounds neat.  Fortunately, Ape doesn't have to be aware of this. :-)

> - Leveraging SVN's property management.  Content in SVN has
properties, much
> like Zope does.  I haven't looked at it yet, but I've noticed
".properties"
> file appearing ... I'm guessing those are the Zope properties, which
would
> be better handled by subversion's property mechanism.  And properties
are
> versioned too !

I think you'll find this easy to do once you implement 
IFSReader/IFSWriter.

> In the realm of the wishful thinking, there's even more:
> 
> Right now, HEAD (Latest/youngest revision) is always used and worked
with.
> The really powerful feature I want to eventually get to is publsihing
> something of a given revision, while editing another.  One potential
> paradigm for distiguishing between the two modes of operation could be
to
> use anonymous vs. authenticated.  This is not useful to everyone, but
can be
> in certain circumstances, most notably where authenticated =
> authors/developpers and anonymous = normal users.  This however
requires ZMI
> interfaces, and in my case CMF ones as well ... This would be global
though
> ... Eventually it'd be nice to have per object control of this stuff.
Andy
> McKay says it can't be done, anybody care to contradict him ? :P I
image I'd
> have to monkey pathc something DEEP in the Zope code base, but I find
the
> mix-in class that's the commonn denominator ... why not ?

Well, CMFStaging is designed to address this need.  To do this at the 
database level, you could use versions.

> Right now I've been working within the "fs" module of apelib.  I'm
going to
> split it off into a seperate one so that it's a clean merge with Ape's
code
> base, in case someone wants to try it, or it eventually makes into
Ape's
> default distribution ?? ;)

You can add a new module, perhaps 'svnops.py', to the 'fs' package.
Then 
we should make the choice between fileops and svnops configurable.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Brad,

About the branch thing ... That's basically the idea!

The bigger problem here is how to "manage" this both internally and from a
user/administrator perspective.

This paradigm only really makes sense in the CMF world anyways, and I want
to focus on basic Zope before moving up to the extra layer CMF represents.
I'm also worried getting something like this to work with CMF woudl require
an ungodly amount of monkey patching :P

The main things with CMF would be:

1) "published" type states vs. other states: how does one tell/define the
difference ? How does this information get passed to/from the publishing
system or the storage layer ?

Possible solution: Have the subversion/zope interface interact with
DCWorkflow.  When an object is changed, consult DCWorkflow settings and
determine what state the object is in.  If the state is deemed "published",
copy the object into the publishing branch.

2) If we got this far, then I need to know when to use the branch vs. the
trunk.  From a user prespective this isn't too big a deal, a ZMI interface,
cookies, etc ... That's all ok ... The problem is that by the time the
request comes to the storage side of things, that information is most likely
gone (Don't know though, I'm still learning).  Then there's the whole
caching thing that would probably complicate things.

2) Message logging: CMF "comments" when doing a workflow action could go
straight into SVN's logging, again how this might be accomplished isn't
clear as of yet.

This is all for the future though, I'm nowhere near this yet!!

Also, I'm thinking the cooler features may just have to wait for Zope 3 ...
Implementing them in Zope might be too convoluted.

I should probably start a Wiki on this topic !

J.F.


-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 13/04/2004 8:40 AM
Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
revis   ion based storage for Zope ?)

On 12 Apr 2004 at 18:03, [EMAIL PROTECTED] wrote:

> 
> Anyways, I'm just rambling by now ... Comments, thoughts and
constructive
> criticism welcome !

This sounds wonderful!

Regarding versions. Perhap you can have a control panel setting that
selects the 
branch to publish "by default". The ZMI could offer another mechanism
that uses 
cookies to select the desired "branch or version"  That is, a branch
name or "PREV, 
HEAD" etc.

But, I use jEdit and FTP for most of my Zope work, so would really like
to have a way to 
access version/branches via FTP. Maybe that can be done by having pseudo

subdirectories named after revisions or branches. So
/myFolder/.Prev/index_html 
would do what you expect (note you can't save to old versions anyway ..)




-- 
Brad Clements,[EMAIL PROTECTED]   (315)268-1000
http://www.murkworks.com  (315)268-9812 Fax
http://www.wecanstopspam.org/   AOL-IM: BKClements


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois . Doyon]

Hello,

Hmmm, well it's as stable as Ape and Subversion are respectively :)

I wouldn't call it stable no, it's something I did over the long week-end we
just had, and that's about it :)

Ape is at 0.8 and therefore becoming quite mature, I'd have to let others
speak as to it stability however ...

Subversion is also probably quite stable (It just reached 1.0), though I
don't know how heavily tested it's been in a long running process (Might it
have some memeory leaks ?) ...

Basically, I wouldn't recommend for usage yet.  I'm not even distributing it
just yet, mostly simply because right now it's code is still intermingled
with Ape's ... As soon as I pull it out into a seperate product I'll be sure
ot post it on zope.org and notify the list, as I'm sure I'll be looking for
feedback/testers.

I would estimate that moment to be weeks away though ...

Thanks,
J.F.

-Original Message-
From: Arthur Chan Chi Chuen
To: Kapil Thangavelu; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 13/04/2004 2:13 PM
Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
revis ion based storage for Zope ?)

Hi all,

I've read your discussion about version control, it seems a cool thing
you 
guys making good progress. Btw, can I ask is the Ape using Subversion in
Zope 
stable? how able CMF stuff? I wanna make/find a document management
system 
which can provide some kinda version control in Plone.

Thanks
Arthur
On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote
> On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED]
wrote:
> > G'Day,
> > 
> > Well, step one is done ... I now have Zope + Ape using Subversion as
it's
> > "filesystem" !!
> >
> 
> cool!
> 
> > This is step one because, as Shawn suggested (Thanks for the
pointer, 
that's
> > what I needed!), this simply means that Zope uses SVN purely as a
> > filesystem.
> >
> 
> > Because of subversion's nature, I want to look at 2 things beyond
this 
that
> > traditional filesystems don't support:
> > 
> > - Use zope's username for SVN logging.
> 
> using AccessControl.getSecurityManager().getUser().getId() and 
> setting it up as a revision prop ( or directly when creating the 
> repo transaction) should do it.
> 
> > - History/Undo support: View past revisions of an object, and revert
to 
such
> > a past revision.
> 
> perhaps the code for this would be helpful, (remove image for code 
> link) 
http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevi
sions.
png
> 
> > - Zope Version support: SVN is fully transactional and atomic, this
should
> > allow for support of Zope versions (I think ?)
> >
> 
> zope version support isn't really all that worthwhile, esp in a cmf
> context. in general zope's version support (or zodb more 
> particularly) is a database level feature masquerading as an 
> application one. since objects modified in a version are in essence 
> locked from participating in other transactions, actions like 
> modifying content in a version in a cmf site amounts to locking the 
> catalog from changes outside of the version, which amounts to 
> shutting down write activities to a cmf site. otoh, integration with 
> zope's transaction manager would be a good thing, although its 
> problematic to integrate between svn and zope txn models, more on 
> that in a moment.
> 
> > In the longer term, there's great opportunity for:
> > 
> > - "Built-in" conflict management and resolution: No more need for a
> > "SafetyBelt" type approach.  Right now I haven't looked at this at
all.  I
> > plan to implement smart merging where possible (It might work
already
> > actually, I just need to test it).  True conflicts (Where a merge
can't be
> > accomplished withouth user interaction) would raise some sort of
conflict
> > error.
> >
> 
> i don't know that conflict management is really useful in this
context.
> svn like zope relies on optimistic concurrency control, and currently
> doesn't support dav locking (which zope does). ie, it will just 
> throw an error if the content has been changed since the transaction 
> began. the 'normal' concurrency control of svn is better but 
> dependent on using the working copy (wc) layer, which is additional 
> programming and storage overhead. so at the layer of the svn client 
> this is already done and working and good, but integrating this 
> functionality into zope is a bit harder without wc overhard.
> 
> this also makes the transaction integration becomes harder because
both
> zope and svn are using what amounts to optimistic concurrency control
> which makes it impossible afaics, to get real txn integration, ie in
> zope's two phase commit strategy, the last chance for a participant 
> to safely abort is tpc_vote, but there is no real way of knowing if 
> the svn txn will suceed or not until its tried. if it is tried at 
> this stage and succeeds then there is the possibility of a latter 
> txn participant failing the tpc_vote and the txn being aborted, and

Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)

[Jean-Francois . Doyon]

G'Day,

Well, step one is done ... I now have Zope + Ape using Subversion as it's
"filesystem" !!

This is step one because, as Shawn suggested (Thanks for the pointer, that's
what I needed!), this simply means that Zope uses SVN purely as a
filesystem.

Because of subversion's nature, I want to look at 2 things beyond this that
traditional filesystems don't support:

- Use zope's username for SVN logging.
- History/Undo support: View past revisions of an object, and revert to such
a past revision.
- Zope Version support: SVN is fully transactional and atomic, this should
allow for support of Zope versions (I think ?)

In the longer term, there's great opportunity for:

- "Built-in" conflict management and resolution: No more need for a
"SafetyBelt" type approach.  Right now I haven't looked at this at all.  I
plan to implement smart merging where possible (It might work already
actually, I just need to test it).  True conflicts (Where a merge can't be
accomplished withouth user interaction) would raise some sort of conflict
error.

- Editing Zope content objects through interaction with the svn repository.
I can checkout the repository, edit some objects, and chek them back in,
never interacting with Zope directly ... I've already tried this !  Works
great for text based content types such as PageTemplates or DTML Documents
and so on ... I even did it with a JPG, though because the properties hold
width and height, you get some weird looking pictures :) The concept is
valid though.  There may someday be a way to leverage this functionality
better with a purpose built client of some sort.

- Leveraging SVN's property management.  Content in SVN has properties, much
like Zope does.  I haven't looked at it yet, but I've noticed ".properties"
file appearing ... I'm guessing those are the Zope properties, which would
be better handled by subversion's property mechanism.  And properties are
versioned too !

In the realm of the wishful thinking, there's even more:

Right now, HEAD (Latest/youngest revision) is always used and worked with.
The really powerful feature I want to eventually get to is publsihing
something of a given revision, while editing another.  One potential
paradigm for distiguishing between the two modes of operation could be to
use anonymous vs. authenticated.  This is not useful to everyone, but can be
in certain circumstances, most notably where authenticated =
authors/developpers and anonymous = normal users.  This however requires ZMI
interfaces, and in my case CMF ones as well ... This would be global though
... Eventually it'd be nice to have per object control of this stuff.  Andy
McKay says it can't be done, anybody care to contradict him ? :P I image I'd
have to monkey pathc something DEEP in the Zope code base, but I find the
mix-in class that's the commonn denominator ... why not ?

Right now I've been working within the "fs" module of apelib.  I'm going to
split it off into a seperate one so that it's a clean merge with Ape's code
base, in case someone wants to try it, or it eventually makes into Ape's
default distribution ?? ;)

Anyways, I'm just rambling by now ... Comments, thoughts and constructive
criticism welcome !

Thanks,
J.F.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Shane Hathaway
Sent: April 8, 2004 11:20 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Using a truely revision based storage for Zope ?


[EMAIL PROTECTED] wrote:
> I've started looking at the ZODB and APE packages to try and get some
> understanding of how the whole storage interaction works, but it'll take
me
> some time to figure it all out ... So I thought I'd get feedback on the
idea
> first ...

Sounds great!  If I were you, I would start by replacing 
Ape/lib/apelib/fs/fileops.py with something that uses the Subversion 
module.  It's a very simple module and you should be able to get pretty 
far that way.

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Using a truely revision based storage for Zope ?

[Jean-Francois . Doyon]

Hello,

A co-worker of mine had an idea I thought was interesting and would like to
investigate further.

First of all, the history behind:

We had requirements for:
- Out of synch editing: Editing objects that are currently "published"
and publishing those only once they've been workflowed (Obviously we're
using the CMF here).  This is currently achieved using multiple servers, one
with a pubished version of the content, and another where the workflow and
editing happens.  Pretty standard stuff.
- Out of synch publishing.   certain pieces of content can be published,
regardless of the state of the parent or vice versa.  Something like I edit
a parent, I edit a child, I want to edit a child despite the parent being in
a unpublishable state, and so on.  this gets conciderably more complicated.
Said co-worker went through alot of pain to do manage multiple content
trees, do tree diff'ing and so on.
- Archiving of all these versions of content.
- Handling of multilingual content.
- more that are too specific to our need to mention here, basically,
highly complex workflows and content types.

So something has been developped that meets these requirements, and it's
complicated as hell.  The development side wraps content objects to make
them multilingual, there are 3 content trees maintained.  In some cases the
content types differ on both sites due to workflow requirements and the fact
that the publshing side was already being developped.  (Developement was
disjointed, an unfortunate situation, but couldn't be avoided).

So out of all this, I'm really wanting a better way to do this.  Althogh it
works, it's rather complicated to maintain, and some of it requires changing
the way certain things are done when developping content.

So the basic theory is: Wouldn't it be great if we could just have a storage
system for Zope that is truly revisioned (I will use this term instead of
"versions" as not to get mixed up with Zope versions) ???

i.e. A system where a given object would exist twice somehow ... The
revision for publishing, and the other revision going through
workflow/editing/etc ...  This alone would solve many of the requirements
above without the need of many servers and publishing/development/pending
tree magic.

So my first big question is this:  Do Zope internals provide enough
flexibility to support such a storage system ? A storage system that
actually stores, in a basically permanent fashion, the various revisions of
an object ? (I don't mean just historie's/undo's, i mean revision controlled
objects in the SCM type sense).  Can Zope be made to publish an object using
one revision of it, while editing another ? Without re-writing the whole
thing of course :)

Here's what said co-worker (I keep saying that because he deserves credit
for what I think is a great idea) came up with:

Using Subversion, and it's Python API, as the storage system for Zope!

Perceived benefits:
- Revisionned objects: Just remember what revision of the object you
want published, and use that ... Editing/Workflow and so on can happen on
further revisions. At some point the revision to be published gets changed,
and voila.
- Efficient storage due to the fact it stores only the differences ...
- Call back hooks are available in the python API, so there can be
notification of changes in the storage, which introduces interesting
possiblities for shared storage, ZEO style.  I don't know how ZEO works
internally,  but I know there's the notification system to expire content in
the caches of the clients.  Does ZODB do the "notification" or is it in the
ZEO code layer ? In this case, the storage itself could provide
notification.
- Full archival of the objects over time, efficiently.
- Benefits from subversion's storage with is BDB 4.2 right now ...
- Possibility of benefitting from SVN's "cheap copy" mechanism (sort of
OO based, references are used until the content changes).
- Many others I'm sure ...

I've started looking at the ZODB and APE packages to try and get some
understanding of how the whole storage interaction works, but it'll take me
some time to figure it all out ... So I thought I'd get feedback on the idea
first ...

Thoughts, comments ?

Thanks,

Jean-François Doyon
Internet Service Development and Systems Support / Développement des
services et soutien de systèmes Internet
GeoAccess Division / Division GéoAccès
Canada Center for Remote Sensing / Centre canadien de télédétection
Natural Resources Canada / Ressources naturelles Canada
http://atlas.gc.ca
Phone: (613) 992-4902
Fax: (613) 947-2410


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )