Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 7. Oktober 2007 01:46:50 -0300 David Pratt <[EMAIL PROTECTED]> 
wrote:



Hi Andreas. Let me say I see the development paradigms as being the
following without prejudice to any application that depends upon zope 3.
Respectfully, no one is building walls. my contribution to the discussion
is not about isolating folks but of the reality of the software
differences.

zope 3 - an open framework - no borders, no boundaries - write and think
as a python programmer. In essence zope 3 is is a framework without a
frame. This fact that exists in this form gives it its elegance and
power. It does not need to be an application and is more interesting when
it is not.

zope 2 - an application tied strongly the cmf with the notion of a cms as
the app. It is self contained and it is able to absorb zope 3 packages
and technologies. I see plone as an application layer build on top of the
zope 2 application.


We don't need to start a discussion about the architecture. Both versions 
have a different history and a different architecture but they serve 
basically the same purpose: building web apps in the first place.

And both versions play nicely together. I assume there are currently
much more Zope 2 developers or Zope 2 developers also developing with Zope 
3 than pure Zope 3 developers...so it is basically having the pure Zope 3 
developers together with all other Zope developers. It would be dangerous
to split up both parties. Zope 2 developers need to know what's going on in 
Zope 3 _and_ vis-versa. The initial argument about more email traffic on a 
common list is only a spurious argument. Both -dev lists mostly contain 
posting with reasonable subjectsscanning some more mails per day really 
is not an issue. I am also subscribed to the zope3-dev list and I am not 
reading everything but at least watching the list gives me an impression

about current discussions and current issues that might be of interest
for the Zope 2 world.

Andreas


pgpX9An982JI4.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: AW: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 6. Oktober 2007 13:40:46 -0400 Stephan Richter 
<[EMAIL PROTECTED]> wrote:







Although you are a Zope component-only  developer
you can not ignore the dependent applications and framework.


So you are saying I have to change Zope 3's story to cope with Zope 2's
identity crisis? Honestly, degrading Zope 3 to a set of libraries and
components is marketing poisoning for people deploying pure Zope 3
applications.


Marketing  'Zope' to new people is one point. Doing "internal marketing" 
for Zope is another big problem. By "internal marketing" I mean the 
following: my major customer is one of biggest Zope 2 users in Germany. We 
use Zope in various large scale installations for internal apps, for 
portals, shops and have more 100K Zope 2 installations running on Windows
Desktops alone in Germany. I am trying to promote Zope 3 technology since 
years within our big development department. And it always comes to 
discussions and misunderstandings as soon the terms Zope 2 and Zope 3 pop up
(...is it compatible?...how can we integrate it with current apps?..and so 
on). It's not about degrading Zope 3 to whatever...it's basically about 
names and the reception of the term 'Zope'.  Accidentally Jim brought up

the same point within his posting today about what Zope 3 stands for. Zope 3
right now is both an application server and a set of components. Let's call
the component part 'Zope components' and the app server part 'Bob'.

How Grok? Grok does not compete with Zope app server since it has complete 
different name. We can tell the people "Grok is a framework for building 
webapps on top of Zope technology which implicit configuration etc...".
With Zope 2 and Zope 3 we have always the problem answering "can I run my 
Zope 2 XXX software with Zope 3"...that's why we need a clear idea about 
what 'Zope ' means. You're right.this is about marketing - both to Zope 
developers and non-Zope developers...but a clear and consistent marketing 
is absolutely necessary since we compete with other frameworks. Zope is no 
longer the top dog within the world of Python frameworks.


Andreas





pgpS5mbFABRMc.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: AW: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 6. Oktober 2007 18:24:45 +0200 Roger Ineichen <[EMAIL PROTECTED]> wrote:


Hi Andreas


What do you man by "two development paradigms"?

Please don't build a wall between Zope 2 and Zope 3
developers. Most "old-school" Zope 2 developers are doing
development also with Zope 3 components and Zope 3
techniques. Look at Plone 3.0 and its heavy usage of Zope 3
techniques...impressing. The Zope 3 development paradigms are
highly accepted by most Zope 2 core developers...we are all
sitting in the same boat. There is a fundamental difference
in the Zope 2 and Zope 3 architecture but little difference
between the paradigms how we should design and write software
on top of the Zope platform in the future.

The distinction between Zope 2 and Zope 3 must disappear. We
must speak of "Zope". Everything else is counterproductive
when it comes to promoting Zope. There is only one Zope
developer community and most of us have a Zope
2 and a Zope 3 hat on (others have a CMF or a Plone head). An
artificial separation between Zope 2 and Zope 3 developers is
undesirable in my opinion.


You are using 7 times the term "Zope2" and 9 times "Zope 3"
and also "Plone 3.0" in this small text. Can you try to describe
this without "2 or 3" in "Zope *"? I guess not, right?


s/Zope 2/Zope application server
s/Zope 3/Zope components






I really don't care about how it is called, but I'm sure we
need some naming convention and since we have one, I don't see
any reason to change this.


As said: there was a big discussion on the terms "Zope 2" and
"Zope 3" during the last DZUG conference. Bringing it to the point:
the terms "zope 2" and "zope 3" should die. There's only 'Zope'.



You also use the term "Plone 3.0" which you implie that we
know that you mean the Plone which uses Zope 3 components ?




You are respecting the postifx 3.0 in the Plone world but
not for Zope? why?


Plone is an application but not a framework. Plone does not have
an identify crisis as Zope.




I'm a little confused and don't understand why you are lobbing
for such a renaming and at the same time you are using this
terms so heavy.


Why? There are much, much more applications deployed on top of the Zope 
application server than on top of the Zope component architecture. There is 
a huge installation of Plone site on top of the Zope app server and now the 
Zope component framework. Although you are a Zope component-only  developer 
you can not ignore the dependent applications and framework. The Zope 
application server core team is always in communication with the CMF and 
Plone teams (we play nicely together (mostly)) and I do expect the same
within the Zope world. The merging of the lists is just one multiple steps 
for bringing the two side together.



Andreas

pgpL2CrWnTW0b.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 6. Oktober 2007 12:03:06 -0300 David Pratt <[EMAIL PROTECTED]> 
wrote:



I agree with you Roger. I want things to stay as they are for the same
reasons. I have great respect for Zope 2 developers however there there
are two development paradigms at play that are fundamentally incompatible
despite the inclusion of component architecture in Zope 2.



What do you man by "two development paradigms"?

Please don't build a wall between Zope 2 and Zope 3 developers. Most 
"old-school" Zope 2 developers are doing development also with Zope 3 
components and Zope 3 techniques. Look at Plone 3.0 and its heavy usage of 
Zope 3
techniques...impressing. The Zope 3 development paradigms are highly 
accepted by most Zope 2 core developers...we are all sitting in the same 
boat. There is a fundamental difference in the Zope 2 and Zope 3 
architecture but little difference between the paradigms how we should 
design and write software on top of the Zope platform in the future.


The distinction between Zope 2 and Zope 3 must disappear. We must speak of 
"Zope". Everything else is counterproductive when it comes to promoting 
Zope. There is only one Zope developer community and most of us have a Zope 
2 and a Zope 3 hat on (others have a CMF or a Plone head). An artificial 
separation between Zope 2 and Zope 3 developers is undesirable in my 
opinion.


Andreas

pgpkMzAHd5fv7.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 6. Oktober 2007 08:14:10 -0400 Benji York <[EMAIL PROTECTED]> wrote:


Andreas Jung wrote:

we want to get rid of the term "Zope 3" in the future




The confusion for people with the terms and Zope 2 and Zope 3 was
one of major topics of the last german Zope conference. And there
were also talks between the DZUG and the ZF on this topic and there
was agreement that we should speak of "the zope application" and "zope
components"  - however this topic belongs on desk of the Zope foundation.

-aj

pgpcfSCx21IDq.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 6. Oktober 2007 03:16:53 +0200 Roger Ineichen <[EMAIL PROTECTED]> wrote:


Betreff: [Zope3-dev] I'd lobe to merge the zope3-dev and
zope-dev lists


Any objections?

This would basically involve retiring the zope3-dev list and moving
zope3 developers to the zope-dev list.


-1

Not that I'm not interested in what's going on in Zope 2,
but the two list let me easy separate this two different
topics. And it will allow me to read the Zope2 mails in
digest mode if I don't have time to read all.


That's a bit shortsighted. First we want to get rid of the term
"Zope 3" in the future (since it confuses ppl). Second: decisions and 
discussons made in the Zope components world have an impact on the Zope 2 
world. Sorry to say but the Zope components world is not an island.


Andreas

pgpY19teibECj.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists

[Andreas Jung]

--On 4. Oktober 2007 15:15:40 -0400 Stephan Richter 
<[EMAIL PROTECTED]> wrote:



On Thursday 04 October 2007 09:57, Jim Fulton wrote:

This would basically involve retiring the zope3-dev list and moving  
zope3 developers to the zope-dev list.


-1. I do not follow zope-dev at all and the traffic is pretty high there.



Not as high as on the zope3-dev list.

+1 for phasing the "zope3" term  out.

-aj

pgpxQcMv4o99u.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: What does python 3000 mean for zope?

[Andreas Jung]

--On 1. September 2007 21:40:20 +0200 Martijn Faassen 
<[EMAIL PROTECTED]> wrote:



Hey,

David Pratt wrote:

 Ultimately, the
folks that will even want to maintain a 2.x code base will quickly erode
 since the forefront of development is never the past. Perhaps it will
all move more quickly for this reason when python 3K is out for real.


This is what I fear will happen. This could mean either some huge
codebases in Python 2.x are going to be left behind in some kind of
ghetto, or that the single community will fracture into a Python 2.x and
a Python 3.x community. Both scenarios suck, so I certainly hope I'm
being pessimistic about this.



Nothing more to add..a separation of the Zope community into Python 2.X and
Python 3.X is the last thing we need (and could afford).

Andreas

pgpUgnp2iNnX5.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: What does python 3000 mean for zope?

[Andreas Jung]

--On 1. September 2007 16:21:23 -0400 Stephan Richter 
<[EMAIL PROTECTED]> wrote:



On Saturday 01 September 2007 15:33, Martijn Faassen wrote:

I think Zope will be on Python 2.x for many years to come.


I really hope not. A friend of mine and I want to get a bit involved in
Python  3000 once it is stable enough that the standard libs can get some
attention.  At this point I really want to have an initial look at
porting Zope 3  packages to Python 3. I really hope we can move to Python
3 in a reasonable  amount of time.



What are the major benefits from moving to Python 3? The major and most 
important change I see in Py3K is the string-as-unicode implementation.
That's a big advantage. However everything else is in some way syntactical 
sugar. Py3k still won't run on multiple CPUs, it still uses the GIL... 
improvements in this area would be arguments for me to move to Py3K.
Only speaking for my self, I don't see major improvements that would my 
daily Python experience significantly.


Andreas

pgp1rdvpI3Z8N.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: What does python 3000 mean for zope?

[Andreas Jung]

--On 1. September 2007 16:33:58 +0530 Baiju M <[EMAIL PROTECTED]> wrote:


Andreas Jung wrote:

 --On 1. September 2007 16:00:19 +0530 Baiju M <[EMAIL PROTECTED]>
 wrote:
> May be we can try Python 3.0 porting in next GSoC ? :)
>

 -1 on that. I am pretty sure that this will lead to two different
 codebases which are hard to maintain over long period of time. We
 should stick with Python 2.X for the time being. Otherwise we risk
 compatibility issues with the current deployed Zope installations. We
 must not jump on every train just because it  stop in front of out
 door.



I hope your "-1" is for porting to Python 3.0 in next year itself.
May be we should consider it after Python 3.0 final release ?
Otherwise how long will be the "time being" ?

If packages like ZODB, zope.interface & zope.component is
not ported that will be great loss for Python 3.0 programmers.



I am basically speaking here for the Zope 2 world. If we move core 
components to Python 3000 we have to move the complete Zope 2 core to 
Python 3000 which will cause a huge disaster because of almost every third 
party component is likely to break. This is a big risk for the reputation 
of Zope.
I currently don't see how a smooth transition would look like. At the end 
will have Zope 2 for Python 2.X, Zope 2 for Python 3.X and Zope 3-ish
components for Python 2.X and different components for Python 3.X...appears 
as a nightmare to me.


Andreas

pgpyzMhrXTDSI.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: What does python 3000 mean for zope?

[Andreas Jung]

--On 1. September 2007 16:00:19 +0530 Baiju M <[EMAIL PROTECTED]> wrote:




May be we can try Python 3.0 porting in next GSoC ? :)



-1 on that. I am pretty sure that this will lead to two different codebases 
which are hard to maintain over long period of time. We should stick with
Python 2.X for the time being. Otherwise we risk compatibility issues with 
the current deployed Zope installations. We must not jump on every train 
just because it  stop in front of out door.


-aj

pgpiX73whYL95.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: [StabilizeEggPackages] (edit) Is that all that has to be done in setup.py?

[Andreas Jung]

--On 29. August 2007 16:15:36 +0200 Wichert Akkerman <[EMAIL PROTECTED]> 
wrote:




I don't like the overly long PyPI pages, but I do really like having
easily browsable documentation online. PyPI is the only places where
that is possible at the moment.

Pointing people to svn.zope.org to read documentation is not an option
in my opinion: finding and reading documentation would require a dozen
extra mouseclicks.


I also prefer the overlong Pypi pages as long as there is no chance to jump
_directly_ from PyPI into the related documentation section. Clicking on 
some svn.zope.org link and clicking through the directory structure is

not a very option from the usability prospective (even for experienced
programmers).

Andreas



pgpcga52BvtBd.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository

[Andreas Jung]

--On 25. August 2007 08:51:44 -0400 Benji York <[EMAIL PROTECTED]> wrote:


Fred Drake wrote:

On 8/24/07, Stephan Richter <[EMAIL PROTECTED]> wrote:

But if you prefer consistency, then we really should be staying with
the Zope 3 style guide,


This, of course, all depends on the answer to the question:
Consistency with what?  Zope 3 history?  The larger Python community?
(Don't think the world agrees on PEP 8...)


Because my desire is to make individual "Zope" packages more widely
adopted by the larger Python community and bring more people to Zope 3, I
prefer PEP 8.  As has been said of Python, more Python code will be
written in the future than has been in the past, I hope the same is true
of Zope.   Hopefully, there are also more Zope users to come than we have
ever had.

Consistency is good, but we have to be consistent with the largest body
of code/group of people as possible.



Can someone please point out the major differences concerning Python code
between PEP 8 and the Zope 3 style guide?

-aj 

pgpl3EWCRn8Tj.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository

[Andreas Jung]

--On 24. August 2007 19:55:35 +0200 Dieter Maurer <[EMAIL PROTECTED]> 
wrote:



Andreas Jung wrote at 2007-8-24 19:35 +0200:

...
Whitespace rules have a major impact on the readability of code.
Readability is a major point when we talk of code quality. Readable code
does not make code automatically but good code has to be readable.


Lots of whitespace does not make the code more readable for all
persons -- it does not for me, for example.

Other rules are more important:

  *  use speaking names

  *  ensure that a "unit" (e.g. a function definition) can been seen in
its  whole

  *  carefully document complex operations

  *  combine a general overview with detailed source documentation.


ACK on everything of that. But reading code comes before understanding code.
And the visual impression of code has a strong impact on how we read code 
and on how we understand code. Rules (written or unwritten) exist to 
organize a certain aspect in life, work etc. Rules are (usually) made to 
satisfy the needs of a majority. If we organize code in a common repository 
then the code styles  (or call them rules) tell the individual programmer 
how most programmers would expect how good code should like. When we write 
code and check it into a public repository the code was written to solve a 
particular problem but it has to follow the most basic rules that are set 
by the developers community as a whole. There is always place for personal 
preferences however there is some border..


Bringing it back to the point: Understanding matters, reading comes before 
understanding so rules about whitespaces, # of statements per line etc.

really matters.

-aj

pgplqywBcAgHk.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository

[Andreas Jung]

--On 24. August 2007 19:27:23 +0200 Dieter Maurer <[EMAIL PROTECTED]> 
wrote:


I find it very stupid to prescribe whilespace rules and


Whitespace rules have a major impact on the readability of code.
Readability is a major point when we talk of code quality. Readable code 
does not make code automatically but good code has to be readable.



'_' separation versus camelCase spelling.


Ack.

-aj

pgpic2FxlUE9h.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository

[Andreas Jung]

--On 24. August 2007 12:21:24 -0400 Fred Drake <[EMAIL PROTECTED]> wrote:


On 8/24/07, Andreas Jung <[EMAIL PROTECTED]> wrote:

We should not be too pendantic when it comes to coding styles. I assume
that most contributors to Zope 3 or Zope components know how to write
code the Zope 3 way.


As the community grows, this is an increasingly poor assumption.
Different developers come to Zope with different background experience
and from environments that have their own coding styles.


My statement was focused on discussions like camel case vs. underscores.
Such discussions are basically academic. In real life when you develop
software for different companies or projects it is hard to switch your
personal coding styles from project to project. In my experience you adopt
the Zope 3 style guide also to other projects outside the Zope world.
But let's be pragmatic at some point...




Now with Philipp's guide we have a document telling people
how to do it the right way.


I don't think that's what this is.  This is a document describing how
things /are/ done in the Zope 3 repository.  That's helpful both as it
stands and as a foundation for a document on how things should be
going forward.


What's the difference? :-)

-aj



pgp9faw3M2D4R.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository

[Andreas Jung]

--On 24. August 2007 09:25:14 -0400 Stephan Richter 
<[EMAIL PROTECTED]> wrote:



On Thursday 23 August 2007 20:37, Philipp von Weitershausen wrote:

I would like to get your comments on it. No matter what this evolves to,
I wouldn't mind eventually seeing it set in stone with your blessings,
so that the checkin police can use it as the highway code to issue
tickets to anyone who's speeding on the repository lane.


I don't like the section on coding style. A while back we agreed that
people  can choose it freely as long as every package in the *namespace*
has the same  style. So for example, ``zope`` and ``z3c`` use the
original Zope 3  styleguide, while ``zc`` uses PEP8 compliance.

This is much easier to keep track of than having to remember every
package's  style.

I personally do not like underscore-style method naming, so I would never
use  it for packages that I am starting from scratch. I do honor other
people's  decisions though, and would always follow the original author's
style.  Consistency is better than correctness in this case. (I usually
tend to value  correctness higher than consistency.)



We should not be too pendantic when it comes to coding styles. I assume 
that most contributors to Zope 3 or Zope components know how to write code 
the Zope 3 way. Now with Philipp's guide we have a document telling people 
how to do it the right way. We still have the stick in our bag for the case 
of the cases...


Andreas




pgpod7hrA09mA.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository

[Andreas Jung]

--On 24. August 2007 02:37:01 +0200 Philipp von Weitershausen 
<[EMAIL PROTECTED]> wrote:





http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-so
ftware.txt



Thanks for writing this excellent "guide". However I am personally unclear
about specifying the dependencies and their version requirements (but this 
is more a setuptools issue than a Z3 specific one).


Andreas


pgpDOZIoeKX0u.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: SVN: zope.location/trunk/setup.py using pypi as homepage instead of svn.zope.org

[Andreas Jung]

--On 20. August 2007 20:22:50 -0400 Stephan Richter 
<[EMAIL PROTECTED]> wrote:



On Saturday 18 August 2007 17:03, Philipp von Weitershausen wrote:

* Please also don't forget to add a changelog entry in README.txt,
especially if you're adding features. If there's no README.txt yet, this
is a good time to give it one. It should start out with a simple
paragraph and have at least one section called "Changes". You could then
use its contents as the long_description in setup.py. Other packages
(e.g. zope.proxy or zope.publisher) can serve as examples.


Why do the changes have to be part of the README file? That seems no
good. I  think a separate file is much better.



I also prefer having separated files for the README and the changes.

You can easily concatenate both files within your setup.py to generate
the long_description. I doing this for my own projects.

Andreas

pgp7HWwT2N7Rx.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] [zope.sendmail] added encryption support

[Andreas Jung]

I added encryption support (SSL/TLS) to zope.sendmail on a branch:



I would appreciate it if someone could test it against their own
SMTP servers since I could test it only against my own SMTP
server.

Tnx,
Andreas

pgpCpN92naaTE.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] New tags: 3.2.3 and 3.3.2

[Andreas Jung]

FYI, I created tags for Zope 3.2.3 and Zope 3.3.2 (based on the related 
branches) in order proper tags for the upcoming Zope 2.9 and Zope 2.10

releases.

Andreas

pgprLXvtTRK6g.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)

[Andreas Jung]

--On 27. Juni 2007 11:36:23 -0300 David Pratt <[EMAIL PROTECTED]> wrote:


Hi. I've tended to use system python against some better advice, but use
but leave it clean since I am using buildouts. This really has had more
to do with the convenience of using the system package tools for
upgrading such as FreeBSD ports system. I've also been experimenting with
CentOS and Fedora Core - so here yum comes into play.

I think the best advice I have got from the discussion seems to be using
a hand compliled python. I am almost at a point of thinking perhaps it my
be best to use cmmi recipe for most system software on a stripped down
server. I already need to patch a compiler and lxml will also only run on
most up-to-date xml libraries so building these seems to make sense to
make sure it does not choke.



...as Jim taught the audience during his Buildout tutorial some weeks
ago in Potsdam: """System Python is EVIL, EVIL, EVIL"""

Andreas

pgpGQeLsAKUQb.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Can we have a 3.2.3 and 3.3.2 release?

[Andreas Jung]

Hi,

I am currently trying to build the next Zope 2.9 and Zope 2.10 releases.
I would like to ship the release with the latest Zope 3.2 and 3.3 *tagged*
releases. At least Zope 2.9 refers (because of a bugfix) to zope.interface
on the 3.2 branch. I definitely won't make 2.X releases with a svn:external
mixture against branches and tags. Are there any objections creating tags
for 3.3.2 and 3.2.3 based on the current code on the 3.3 and 3.2 branches?
I see also problems coming up when using the satellite projects with their
own release schedule within Zope 2. It will be hard to track changes and 
make a decisions which if of the packages needs to be updated. The Zope 3
meta-egg or how ever we will call it is most important since it has to 
describe the officially blessed versions of all packages.


Andreas


pgprP3ZWiCMJR.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] A thought on backward compatibility and minimum versions

[Andreas Jung]

--On 31. Mai 2007 20:08:02 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote:


Jim Fulton wrote at 2007-5-31 10:12 -0400:


In thinking about how we might specify that we want to depend on
major versions but sometimes need to specify minimum versions, the
following occurred to me:

- Suppose that we always had access to the latest released version,

- Suppose that, within a major release, all releases were backward
compatible,

Then I assert that there is no *need* to specify a minimum release
within a major release.


I fear my colleagues responsible to maintain the productive versions
would not be happy:

  They want the system to be as stable as possible.

  If they need to introduce a new component, they usually
  prefer to just add this one component. Only if this forces
  other updates, they reluctantly will make them.

The motivation for this behaviour: even if a newer version
is supposed to be backward compatible, it often has slightly different
behaviour which may trigger bugs in the other parts of a complex system.


That's why one should have enough tests...although tests will never
cover all cases.

-aj


pgpt1WGkPLSoR.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Zope? PostgreSQL

[Andreas Jung]

--On 23. April 2007 09:20:14 -0400 Ariel Eduardo Morales Malpica 
<[EMAIL PROTECTED]> wrote:



Hi. I'm working on a project and I'm using ZODB but my mentor advices me
that this model of database will be so big after one or two years. He
consider that because ZODB works with transactions and it's added to
ZODB frequently. My mentor mentioned me PostgreSQL, but I don't want it,
because is better for me use Objet Oriented Database than Relational
Database.


You pack and reorganize the ZODB like any other RDBMS. Don't tell us that
a RDBMS won't grow :-)


I don't know what to do.
Is true that ZODB can be so big in few years? I'm implementing a Project
Management System and I fear that it could be a problem after a few
years. (use ZODB).


Your issue isn't really of major interest when making a decision for/against
the ZODB. The decision for example must depend on your data model and how 
relational it is. Both systems have their pros and cons.


-aj

pgpdh3cQwJjbH.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Converter framework on svn.zope.org?

[Andreas Jung]

I remember that there was some converter framework on svn.zope.org dealing 
with different conversions from PDF/DOC etc. -> plain text. Can anyone 
remember the name?


Andreas

pgpPNGg8z4Jpw.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] import Products.Archetypes

[Andreas Jung]

--On 19. März 2007 01:56:41 -0400 Ariel Eduardo Morales Malpica 
<[EMAIL PROTECTED]> wrote:



I'am trying to import Products.Archetypes.atapi module but I can't. I
mean, I can import that module but when I press F9 (I use Eclipse IDE)
with that only sentence (from Archetypes.atapi import *), I don't
include Products because isn't a package and I add the path to
PYTHONPATH. I get an error like this:

"from Products.Archetypes.debug import log, log_exc
ImportError: No module named Archetypes.debug"



You're on the wrong list. Use plone-users mailinglist instead.

-aj

pgp9xnmGn8VOS.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] z3c.sqlalchemy questions

[Andreas Jung]

--On 17. März 2007 11:12:19 +0100 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:



Hi there,

I saw Andreas Jung checked in z3c.sqlalchemy. Cool! Some questions though:

* how is this different from zalchemy?


It's providers better control about the mapper generation and should cover 
all the different use-cases we encounter right now with databases. You have 
certain levels of control about how mappers are generated. But wait

for the documentation :-)



* I see it uses ZopeTestCase, while it appears to be pure Zope 3 code
otherwise, at least at first sight (and because of the package name). Why
is this done?


That's possibly a culprit of a former version. I'll have to clean it up.




* The copyright isn't Zope Corporation. Under the current rules of the
SVN repository (pre-copyright assignment to the Foundation), the
copyright should be assigned to Zope Corporation and contributors. After
transition it'll change again.


No problem. I can change that.

Andreas



pgpYQcBFPr5b0.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] [German Zope Conference] Call for papers open

[Andreas Jung]

From: Andreas Jung <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], zope@zope.org, 
zope-announce@zope.org,

zope-dev@zope.org
Subject: [Zope-Annce] [German Zope Conference] Call for Papers open
Date-Sent: 1. Februar 2007 08:06:52

Dear Zope Community,

the eighth Zope conference organized by the German Zope User Group (DZUG) 
will be held this year at the Potsdam Institute for Climate Impact Research

from 4. to 5 June 2007 (near Berlin). The topic of the conference will be

   Zope in sciences.

Proposals for talks and workshops can be submitted until 01.04.2007;

http://www.zope.de/redaktion/dzug/tagung/potsdam-2007/dzug-conference-2007-call-for-papers-zope-in-science

or

http://www.zope.de/redaktion/dzug/tagung/potsdam-2007/dzug-conference-2007-call-for-papers-zope-in-science

Both German and English proposals are highly welcome.

You can find further information about the Zope conference here:

  http://www.zope.de/8-dzug-tagung


Regards,
Andreas Jung
Assistant Chairman DZUG e.V.


pgpjdTLS7YlH1.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner

[Andreas Jung]

--On 19. Januar 2007 15:08:49 -0500 Benji York <[EMAIL PROTECTED]> wrote:


Andreas Jung wrote:


--On 19. Januar 2007 14:41:53 -0500 Benji York <[EMAIL PROTECTED]> wrote:


Wouldn't that change just defer the error until that function is called?
(which the testbrowser tests do)


The patch solves my problem and the testbrowser tests pass.


I suspect that means the tests are insufficient, but I'm just pragmatic
enough to be persuaded the patch should go in (with a comment as to why
that import is done there).



Done

Andreas

pgp9DZEqYuvcq.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner

[Andreas Jung]

--On 19. Januar 2007 14:41:53 -0500 Benji York <[EMAIL PROTECTED]> wrote:


Wouldn't that change just defer the error until that function is called?
(which the testbrowser tests do)


The patch solves my problem and the testbrowser tests pass.

Andreas



pgpivN2G5VcEl.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner

[Andreas Jung]

--On 19. Januar 2007 14:35:53 -0500 Benji York <[EMAIL PROTECTED]> wrote:


Andreas Jung wrote:

the Zope 2 testrunner has a problem with zope.testing:

<http://www.zope.org/Collectors/Zope/2268>

testbrowser/browser.py tries a  "from test import pystone" import it
picks up the test.py of the Zope 2 testrunner



A workaround would be to move the import above
PystoneTimer.pystonesPerSecond(). Any objections against this workaround?


I'm not sure how that would help, but I'm not exactly sure what you're
proposing, either.  Perhaps if you posted a diff it would clarify your
suggestion to me.



[EMAIL PROTECTED]:~/sandboxes/Zope/Zope/lib/python/zope/testbrowser> svn diff 
browser.py

Index: browser.py
===
--- browser.py  (revision 72034)
+++ browser.py  (working copy)
@@ -16,7 +16,6 @@
$Id$
"""
__docformat__ = "reStructuredText"
-from test import pystone
from zope.testbrowser import interfaces
import ClientForm
from cStringIO import StringIO
@@ -100,6 +99,7 @@
@property
def pystonesPerSecond(self):
"""How many pystones are equivalent to one second on this 
machine"""

+from test import pystone
if self._pystones_per_second == None:
self._pystones_per_second = 
pystone.pystones(pystone.LOOPS/10)[1]

return self._pystones_per_second




pgp4WcghTLEzV.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner

[Andreas Jung]

Hi,

the Zope 2 testrunner has a problem with zope.testing:



testbrowser/browser.py tries a  "from test import pystone" import it picks
up the test.py of the Zope 2 testrunner that tries to re-add some
configuration options to testrunner.setup causing the initial error.
Zope 2 or Zope 3 bug...any chance to get this fixed in zope.testing somehow?
A workaround would be to move the import above 
PystoneTimer.pystonesPerSecond(). Any objections against this workaround?


Andreas

pgpZS1ZOIORY7.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 18. Januar 2007 08:29:57 -0500 Fred Drake <[EMAIL PROTECTED]> wrote:


On 1/18/07, Andreas Jung <[EMAIL PROTECTED]> wrote:

We're faster with new Zope versions than the W3C with any standard.


So?  The recommendation for XML 1.1 is already a done deal (a "second
edition" was published last September), so there are already multiple
specified versions.  Since other version strings are allowed, whether
there's a published specification or not, we don't want to make
assumptions about what's there.


Are the underlying frameworks (TAL, xml.parsers.pyexat) ready for XML 1.1?

-aj



pgpsZe3h8qPY0.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 17. Januar 2007 22:49:11 +0100 Dieter Maurer <[EMAIL PROTECTED]> 
wrote:



Andreas Jung wrote at 2007-1-17 17:48 +0100:

...
So Martijn's and my proposal remain. They are not very different. In the
end the behavior is almost identical. But I will adopt your suggestion
to  remove
the preamble when storing the data internally (basically to avoid a
possible encoding ambiguity).


In future times, the preamble might contain information which
should not be dropped, e.g. when there is an XML version
different from "1.0".


We're faster with new Zope versions than the W3C with any standard.



For PageTemplates, we know that the encoding information is probably
not relevant after the parsing -- unless we want to use it
as a default for the "Content-Type" charset but I doubt that this
is a good thing. If the "Content-Type"'s charset is given explicitely,
then the "encoding" of the XML declaration needs to be
adapted to this value during the serialization anyway -- thus
overriding any "encoding" present there.


?

-aj



pgpGl17OH27Hh.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 16. Januar 2007 14:12:46 +0100 Martijn Faassen 
<[EMAIL PROTECTED]> wrote:



I am replying to the three proposals. First I have to kick the proposal of 
Tres (UTF-8 storage). We want unicode as internal representation for any 
kind of ZPT (both text/html and text/xml). Supporting unicode for text/html 
and utf-8 for text/xml would make code more complicated and lead to further
unicode encoding conflicts. We're trying to solve this issue right now and 
I don't want to introduce a new construction site.


So Martijn's and my proposal remain. They are not very different. In the 
end the behavior is almost identical. But I will adopt your suggestion to 
remove
the preamble when storing the data internally (basically to avoid a 
possible encoding ambiguity).


Andreas

pgpxXQNoRi2gs.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 15. Januar 2007 22:15:46 +0100 Martijn Faassen 
<[EMAIL PROTECTED]> wrote:


My point is that:

u"Some non-ascii
text"

is confusing at best. One part of this says it's a unicode string, the
other part says it's in encoding latin-1.


The string above would be used for internal storage but *not* for 
processing. Btw. this is not different from storing HTML files as unicode 
string. An application must convert the unicode string back to a serialized
string - either to the encoding as specified inside the preamble or to a 
'general' encoding (that covers the unicode database) like utf-8 with 
changing the encoding inside the preamble - both are legitimate approaches.

There is no ambiguity. A smart XML parser will represent a XML document
*independent* of the source encoding in most general way (storing a textual
content a unicode (or utf-8 at least).


I still don't see what should ambiguous with this approach.


Ambiguous in that the string seems to say it's in two encodings at once.
You're then "guessing": you're letting the Python string type trump the
declaration. Then, since we've shown that leads to bugs, you propose
actually change the encoding declaration of the XML document. I wonder
what people then expect to happen upon serialization. In effect, your
proposal would, I think, serialize to UTF-8 only, right? (in which case
the encoding declaration can be dropped as it's the default.


When you download a ZPT through FTP/WebDAV then the unicode representation
of the XML will be converted using the 'output_encoding' property of the
corresponding ZPT which is set when uploading a new XML document (and taken
from the premable). So when you upload an latin1 XML file you should get it 
back as valid latin1 through FTP/WebDAV.


When you download text/xml content through the ZPublisher then the 
ZPublisher will convert unicode textual content to some encoding which is

either taken from an already set 'content-type: text/...; charset=X'
HTTP Header or as fallback from the zpublisher-default-encoding property
as defined in the zope.conf file.

So the application can specify in both case the encoding of the serialized
XML content. Where is the problem?

Andreas


pgpUMJ3Mc5Oh4.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 15. Januar 2007 15:44:01 +0100 Martijn Faassen 
<[EMAIL PROTECTED]> wrote:



Hey,

On 1/15/07, Andreas Jung <[EMAIL PROTECTED]> wrote:
[snip]

ok, got it. But this problem can be solved easily by changing the
encoding within the preamble.


I would say refusing to guess and bailing out with an error message is
better in this case. The Zen of Python:

In the face of ambiguity, refuse the temptation to guess.



Sorry but I don't get your point. What's happening with a XML inside a ZPT?

- XML data encoded as XXX comes in (either by editing the XML file through
  the ZMI or FTP/WebDAV upload)

- ZPT converts the encoded string to unicode based on the encoding in the 
preamble


- for parsing it is up to the application to decide what to do with the 
data. It is not up to the editor to decide how the ZPT engine should deal 
with XML internally. The ZPT engine decides to serializes the unicode 
string as utf-8 and to fix the XML preamble (which will result in a valid 
XML file
which should identical with the original file - except the encoding might 
be different).


I still don't see what should ambiguous with this approach.

Andrea

pgpq0GGi0oSZu.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 15. Januar 2007 14:52:42 +0100 Martijn Faassen 
<[EMAIL PROTECTED]> wrote:



Hey,

Gmane isn't updating so I can't really reply to the message (not visible
in gmane) that I want to, but I saw the following solution proposed:

def ourparse(text):
if isinstance(text, unicode):
   text = text.encode('UTF-8')
xml_parser.parse(text)

now consider what will happen if you do the following:

text = u"Some non-ascii
characters here"
ourparse(text)

what will happen is that text is converted to a UTF-8 string (8-bit
ascii). It's then passed to a hopefully compliant XML parser. This XML
parser sees an 8-bit ascii string, and checks the encoding header for
more information on the encoding of the string. It will therefore assume
the string is in latin-1. The parse will break with an obscure error and
the developer doing this is probably very confused.



ok, got it. But this problem can be solved easily by changing the encoding
within the preamble.

-aj

pgpi1m3ddiYBz.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 15. Januar 2007 13:26:16 +0100 Martijn Faassen 
<[EMAIL PROTECTED]> wrote:




How would you propose to parse the following unicode string?

u""


If your parser is unicode-aware then the encoding of the preamble
does not matter since you have already unicode internally and can process 
your file totally on XML.


If your parser isn't unicode-aware then you will likely convert it to
utf-8 and work internally with utf-8 encoded strings. In fact 
xml.parsers.expat since to support unicode (it can return unicode strings

to the handlers, see 'returns_unicode' property). However you need to
reconstruct the XMl preamble when you reconstruct your XML from the
parsed data.

Or am I missing something?

Andreas

pgpQNy99FMGyu.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 14. Januar 2007 18:14:45 + Chris Withers <[EMAIL PROTECTED]> 
wrote:



Dieter Maurer wrote:

A halfway intelligent parser would accept Unicode when it gets it
and concentrate on the remaining part of its task: either reporting
structural events or building a parse tree.


The trivial fix I use in Twiddler is as follows:

if isinstance(source,unicode):
   source = source.encode('utf-8')

Of course, this assumes a heading of either  or a missing encoding attribute, in which case the xml
spec states that the string must be utf-8 encoded.


The encoding of the XML preamble should not matter when parsing a XML
document stored as unicode string. It is of importance as soon as you 
convert the document back to a stream e.g. when we deliver the content
back to a browser or a FTP client. The ZPublisher (for Zope 2) deals with 
that by changing the encoding parameter of the preamble for XML documents 
based on the desired output encoding. utf-8 is always a good choice however

other encodings like iso-8859-15 might raise UnicodeDecodeErrors. The Zope 2
publisher "avoids" this problem converting the unicode result using 
errors='replace' (which is likely something we might discuss :-))


Andreas

pgpY2ic9Zojnl.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

--On 14. Januar 2007 10:48:06 +0100 Bernd Dorn <[EMAIL PROTECTED]> 
wrote:



I am not sure if this behavior is intentional?! Is the XMLParser
supposed
to deal with unicode strings or will it only accept a standard
Python string? A workaround inside parseString() would to check for
unicode
and convert the string on-the-fly to a Python string with utf-8
encoding.
This is possibly a limitation of the underlying Expat parser...any
recommendation how to deal with this issue?


IMHO it should only accept strings, because in the value should be a xml
string and therefore always has to be encoded in 'utf-8' or in the
encoding specified in the processing instruction.



I disagree with that. Since Zope 3 is supposed to use unicode internally
(at least that's the legend) it should support unicode also at the parser 
level. Other languages like Java store XML also as unicode strings and 
support parsing it.


Andreas



pgp8ib4BIWYFC.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] zope.tal.xmlparser.XMLParser() dislikes unicode

[Andreas Jung]

Hi,

the XMLParser.parseString() method  raises an exception

 File "/opt/python-2.4.4/lib/python2.4/unittest.py", line 260, in run
   testMethod()
 File 
"/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/tests/test_xmlparser.py", 
line 127, in test_xx

   self._run_check(xml, ())
 File 
"/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/tests/test_xmlparser.py", 
line 106, in _run_check

   parser.parseString(source)
 File 
"/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/xmlparser.py", 
line 77, in parseString

   self.parser.Parse(s, 1)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 
43-48: ordinal not in range(128)


if the string to be parsed is a unicode strings and contains some non-ascii
chars. The following snippet from a private unittest (test_xmlparsers.py)
shows the error.

   def test_xx(self):
   xml = unicode('encoding="utf-8"?>üöä', 'iso-8859-15')

   self._run_check(xml, ())

I am not sure if this behavior is intentional?! Is the XMLParser supposed
to deal with unicode strings or will it only accept a standard Python 
string? A workaround inside parseString() would to check for unicode

and convert the string on-the-fly to a Python string with utf-8 encoding.
This is possibly a limitation of the underlying Expat parser...any 
recommendation how to deal with this issue?


Andras






pgpqL51ow2oL9.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: SOAP support?

[Andreas Jung]

--On 8. Januar 2007 10:42:34 -0330 Rocky Burt <[EMAIL PROTECTED]> wrote:


On Sun, 2007-07-01 at 14:54 -0500, Tres Seaver wrote:

  http://wanderingbarque.com/nonintersecting/2006/11/15/

I think that an add-on product which provided a SOAP server,
implementing one of the competing semantics, could be interesting as a
starting point, although it might not be terribly resuable.


While I'm not necessarily a huge SOAP advocate (personally I just want
RPC that works) that pasted link does a *very* good job of portraying a
subjective view on how confusing soap is.  That is... it's only
propaganda.  Sticking with just SOAP (no wsdl, no uddi, no xml schema)
you can make services as simple as xml-rpc.


I fully agree with that. SOAP is widely adopted but everything else
on SOAP might be considers as YAGNI.



Everything beyond standard soap tries to give it an infinite amount of
power that is best compared to the extremely large number of corba
specifications.


This stuff is in some way too overengineered and too complex for being 
adopted in projects. Specs that are only understandable for the editors are 
specs for the trashcan.


Andreas


pgpd99CluCYAC.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: Some ZPT insights needed

[Andreas Jung]

--On 7. Januar 2007 21:53:25 +0100 Dieter Maurer <[EMAIL PROTECTED]> 
wrote:



Andreas Jung wrote at 2007-1-6 20:45 +0100:

...
But it is fact that a lot of applications have to fight
with unicode errors and the common solution seems to be to change Python
default encoding (which is not a good idea in my opinon. People like
Dieter will disagree).


I will agree with you *AFTER* you have implemented a better way.
Apparently, you are working on it...


The stuff is finished. A UnicodeEncodingConflictResolver can be configured
through ZCML (see 2.10 branch, HEAD).

Andreas

pgpZiKLSxn7XZ.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Some ZPT insights needed

[Andreas Jung]

--On 7. Januar 2007 21:46:21 +0100 Dieter Maurer <[EMAIL PROTECTED]> 
wrote:


I think this is a pure Zope 2 problem at this point, no?


Thus, you would not mind that the Zope 3 code is changed at this
place -- as pure Zope 3 will not execute it.


We certainly have way
of handling UnicodeDecode errors. If you can show that this could
potentially  be a problem in Zope 3 as well, I would be for adding your
UnicodeDecode  resolver to the Zope 3 core.


The aim is to have the same "PageTemplate" implementation
for both Zope 2 and Zope 3. Thus, it may be necessary to extend
the common code a bit even when the problems does not occur
in pure Zope 3 code.


The same PT implementation does not mean that we can get rid of
Zope 2 specific stuff within the wrapper code (which is still big
since a bunch of Zope 2 magic must be attached to the Zope 3 PT
implementation).

-aj



pgpHqSwiVzuo8.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] SOAP support?

[Andreas Jung]

Hi,

I am actually looking at options for bringing SOAP support into Zope 2.
Is there some SOAP infrastructure available in Zope 3 (or some add-ons)
and might be re-used in a reasonable way?

Andreas

pgp3pdt4srmvH.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: Some ZPT insights needed

[Andreas Jung]

--On 6. Januar 2007 20:34:15 +0100 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:


This kind of automagic unicode error defeating logic scares me. With
Silva, we have a significant Zope 2 application that already takes care
to output unicode to the page template engine. For a while we were using
PlacelessTranslationService which has some hacks in place to do automagic
conversion from unicode to an encoding. Granted this is the opposite
direction than you are proposing, and my intuition is that your direction
may be less scary, but I'm still scared. Not having unicode errors can
make debugging of pure-unicode applications harder. Bugs sneak in pretty
easily and you end up with non-pure content.



I share your fear. But it is fact that a lot of applications have to fight
with unicode errors and the common solution seems to be to change Python
default encoding (which is not a good idea in my opinon. People like Dieter
will disagree).




I'd therefore like it if there were a way, application-root specific, to
turn off any auto-conversion behavior. Do you think that would be
possible?


I am thinking about providing some handlers with different behavior that 
could be configured on a per-site basis (tied to local site managers). 
However I am not so familiar with site managers so far so I am  currently
playing around and thinking into different directions). But you might think 
f a handler that would implement the current behavior: throwing an exception
or or and handler that uses Pythons default encoding .just some 
ideas...makes sense?


Andreas



pgp7FunlNnQ3V.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Some ZPT insights needed

[Andreas Jung]

--On 6. Januar 2007 12:15:19 -0500 Stephan Richter 
<[EMAIL PROTECTED]> wrote:



On Saturday 06 January 2007 12:03, Andreas Jung wrote:

returns always unicode for non-strings but keeps standard Python
strings as they are.


I think we always require to return unicode text within Zope 3,


which is a good policy


so there
should never be a regular string in there.


this policy must be enforced? :-)



I have some ideas how make resolving UnicodeDecode
error configurable but I am not sure if this code should go into the
Zope 3 or should remain in the Zope 2 core. Does Zope 3 has to deal with
such kind UnicodeDecode errors?


I think this is a pure Zope 2 problem at this point, no? We certainly
have way  of handling UnicodeDecode errors. If you can show that this
could potentially  be a problem in Zope 3 as well, I would be for adding
your UnicodeDecode  resolver to the Zope 3 core.


It's possibly a major Zope 2 issue. However since we are putting more and 
more Zope 3 stuff into Zope 2 is becomes also (in some way) a Zope 3 issue.
I just wonder if it would be better to move more logic into the related 
Zope 2 wrapper code (making it more fat) or putting  it into the Zope 3 
core...

I have to brainstorm about it.



BTW, weren't you in the room when we had the initial discussions pretty
exactely 5 years ago?

Yes, you were! :-)

http://wiki.zope.org/zope3/Feb2002InternationalizationSprint


Oh my god :-) Yet some more years we survived with Zope :-)

-aj





pgp7USG8D73j1.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Some ZPT insights needed

[Andreas Jung]

--On 6. Januar 2007 10:08:11 -0500 Stephan Richter 
<[EMAIL PROTECTED]> wrote:





Yeah, there is. The "engine" does all the expression evaluation work. It
already handles the I18n stuff, so you should be able to do your unicode
conversions there too.

The engine uses an expression context. This expression context has all
sorts  of ``evaluate*()`` methods. Most interesting to you will be the
``evaluateText()`` one.



Thanks. evaluateText() is exactly what I am looking for.
I wonder why the method


   def evaluateText(self, expr):
   text = self.evaluate(expr)
   if text is self.getDefault() or text is None:
   return text
   if isinstance(text, basestring):
   # text could already be something text-ish, e.g. a Message 
object

   return text
   return unicode(text)

returns always unicode for non-strings but keeps standard Python
strings as they are. I have some ideas how make resolving UnicodeDecode
error configurable but I am not sure if this code should go into the Zope 3
or should remain in the Zope 2 core. Does Zope 3 has to deal with such
kind UnicodeDecode errors?

Andreas



pgpVB5RJdUkWj.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Some ZPT insights needed

[Andreas Jung]

Hi,

because Zope 2.10.2+ will use unicode as internal representation for
page templates I am currently checking the options to get rid of
UnicodeDecodeErrors for Zope 2.11 by providing some more intelligent
conversion of non-unicode content. Basically I want if the content returned 
by expressions within a page template if unicode or non-unicode. If it is 
non-unicode it would be converted based on some policy (to be specified) to 
unicode. This would avoid any kind of UnicodeDecodeError (hopefully).
This there a central place in the ZPT code were the evaluated expressions 
are inserted into the rendered HTML or some internal datastructure used for 
rending the ZPT? I just need to know where to look at but I have no idea so 
far :-)


Thanks,
Andreas 

pgp0u915J3wG3.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] Is there an alternative to zdaemon?

[Andreas Jung]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



- --On 22. Dezember 2006 15:55:48 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:
>
> It has 2 major disadvantages:
>
> - It is ours. :)  We are bearing the burden of maintaining it.
>This is offset by the fact that it hasn't required much maintenance.

..which is actually a sign of "it-just-works".

>
> - It is largely undocumented. This makes it much harder to use than it
>needs to be.  It also makes it under appreciated.  I made a start at
>fixing this yesterday:
>
>  http://svn.zope.org/zdaemon/trunk/src/zdaemon/README.txt?view=auto
>
>   It isn't very hard to use, so documenting it isn't really all that hard.

...which is almost True for a lot of parts of the Zope 2 core  :-)


>
> I wonder if we should be using some other daemon manager.  Arguably,
> there's
> no reason for the Zope project to maintain one if something is available
> that does what we need.

I think (meanwhile) that this is not enough to justify the replacement of a 
component. Replacing a Zope 2 component always caused some pain. So as a 
rule for replacing something in the Zope 2 core we consider those rules:

 - the replacement solves  existing functional problems

 - it adds major functional benefits

 - no issues with backward compatibility, well tested etc.

For the Zope 2 core we must be very careful about changing stuff. Stability
and backward compatibility are much, much more important for the end-user 
than satisfying our replace-all-with-something-better drive :-)

Don't get me wrong but we've done some minor mistakes with replacing stuff 
in the past  and because of that I became a bit conservative about changing 
things. Of course I am only speaking for the Zope 2 core.

Andreas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFFjLuICJIWIbr9KYwRAgsRAJ9p3Td7KOmKzHzLn89nnQpSdYMtnwCcDyDR
iKgZV5H76vnCpjqO3Mccrv4=
=DYYW
-END PGP SIGNATURE-

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: Python version for Zope 3.4 ?

[Andreas Jung]

--On 28. September 2006 16:17:54 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote:

We should definitely try to *support* Python 2.5, but we can't require
it till Zope 2 has been "certified" for it.


Why isn't Python 2.5 even supported at present?


There are lots of test failures.  Also, untrusted Python code doesn't
work with 2.5 due to major changes in the compiler. (Zope 3 does almost
no custom Python compiling, but it does do some.)



Also Zope 2.10 dies under Python 2.5 with some famous crashs.

-aj

pgpbvMiP3G4pc.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Naming tags

[Andreas Jung]

The SVN tag names are bit confusing an inconsistent.

The tagname for the ZODB release used for Zope 3.3.0rc1 is 
'3.7-Zope-3.3.0rc1'. Since we want to use the same release for Zope 
2.10.0rc1
I don't like that Zope 3.3 appears within in the tag name. I would 
appreciate it if we could stick with the same naming schema as in the past 
for ZODB (without X Zope specific information).


The Zope 3.3.0rc1 tag is '3.3.0c1'. The ZODB tag uses 'rc' and I would 
appreciate if we could use either 'c' for the release candidate or 'rc'
but not both and not mixed for the same version. My personal preference is 
'rc'.


Andreas


pgpMU1eGLG9aD.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Release management refinements

[Andreas Jung]

--On 13. September 2006 20:12:50 +0200 Dieter Maurer <[EMAIL PROTECTED]> 
wrote:



Philipp von Weitershausen wrote at 2006-9-13 11:05 +0200:

Over the last couple of days we've been discussing Zope's new release
cycle and the release management. I would like to sum up what seems to
be the gist of those discussions:


9 month release period?
---


I am almost convinced that we will make the same experience as
the Plone people: when we strive for a 9 month release cycle, we
will get a 12 month cycle...

I think this is almost a law for software development: completing in
time is the exception not the rule.


That's not the point here. We are discussing about the release periods in 
order to do not flood the community with new versions but not about the 
reasons why we are often running behind our schedule...that's a different 
issue :-)



Andreas

pgpluNfeu86yX.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?

[Andreas Jung]

--On 12. September 2006 16:55:31 +0200 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:





Personally I think we should just release the trunk every six months
(with a list of known bugs) and that be it.  (I'm speaking of Zope 3
here, I don't know enough about the dynamics of the Zope 2 ecosystem to
comment there.)


I think that this is an edge case of time-based releasing: the absolute
minimal work we need to do to make a time-based release is to release the
trunk. Hopefully we'll be doing more than the minimal amount of work, and
we'll actually fix some bugs before we release the trunk. A release can
be a good opportunity to fix lingering bugs, after all.


I am thinking since one hour about how to reply to Benji's proposal. It's
not much acceptable. Major release have to be planned to a certain degree 
and must be tested (as good as we can) - means we must have alpha and beta
releases. Everything else does not make sense to me. Zope 2 is not a 
kindergarten project and we use it for professional projects and we as a 
community should act (somewhat) professional. You can of course make daily 
snapshots available but most developers are using SVN checkouts and 
professional users don't want depend on snapshots - they expect official 
releases.



Andreas

pgp0MBvxjRcPa.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?

[Andreas Jung]

--On 12. September 2006 13:06:05 +0200 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:



Andreas Jung wrote:

--On 12. September 2006 12:28:10 +0200 Martijn Faassen
<[EMAIL PROTECTED]> wrote:

[snip]

Anyway, if the main thing holding up *this* release is bugfixes, doing a
new release in 3 months shouldn't be a problem, as after all, we've
already fixed those bugs this time around. :)


3 month for a new release cycle is just too short. We should not follow
the IMO broken concept of "release early, release often" but to follow
"release regular, release solid". At least me I refuse to release
something just  for the sake of making a release at a certain date.


The current CHANGES.txt from the trunk just lists one new feature (added
by myself). That's does not deserve a major release.



The goal is not release early, release often, but to get back to our
regular release schedule. After all, we already had 3 months to add code
to Zope 2 and Zope 3 trunk that will be included in the next release, as
I believe they branched at the time.


Not much happened during the three month or I did I miss something?


Could you explain the reasons for the coming 3 months being too short in
this particular case? What features are we adding to Zope 2 or Zope 3
that make it too short and thus would result in a not-solid-enough
release?


We just don't have nothing new right now.

Another point with this whole half-yr release cycle: we're going to confuse
more and more professional users about which Zope version to use for what.
I've heard from my major customer but also from other ppl. IN December we 
would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely

can't deprecate Zope 2.9 in December because this version is required
by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate
from Plone 2.1 to Plone 2.5. We have the burden  maintain Zope 2.9 for the
mid-future. So my personal impression right now is: we're flooding the 
community with new major releases and the community does not adapt those
releases. My theory: a major part of the ppl running Zope are running 
Plone.

on top of Zope...so with have to deal with this fact somehow.

Andreas

I think the egg-story is one candidate for being too big, and a possible
reason to shift the release schedule. Then again, we do not need the egg
story to land in the upcoming release anyway.

Regards,

Martijn




--
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting


pgpKzG0VOomAk.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?

[Andreas Jung]

--On 12. September 2006 12:28:10 +0200 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:



Andreas Jung wrote:

since we are three month late with the current releas, it would make
sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?!


Is the reasoning here that since a release cycle has taken 9 months, so
should the next? I'm not convinced expanding the release cycle is going
to make us be on time more.


Not really, just a thought in order to stick with the June/December
cycle...but not really an important argument.




If we want to stick with the half-yr cycles, we need to schedule the
next release for around March/April next yr. Thoughts?


That's one option. The other option is to stick with the plan and catch
up, as Christian Theune proposed. It would mean getting very unambitious,
but perhaps that isn't a bad idea. The idea of a release is to have a
reasonably stable, known-good version of the trunk, and it doesn't matter
that much how much the trunk changes.

Anyway, if the main thing holding up *this* release is bugfixes, doing a
new release in 3 months shouldn't be a problem, as after all, we've
already fixed those bugs this time around. :)


3 month for a new release cycle is just too short. We should not follow the
IMO broken concept of "release early, release often" but to follow "release
regular, release solid". At least me I refuse to release something just for 
the sake of making a release at a certain date.


Andreas



pgpSiZKwtHn0V.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Release schedule for Zope 2.11/3.4?

[Andreas Jung]

Hi all,

since we are three month late with the current releas, it would make sense
to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want 
to stick with the half-yr cycles, we need to schedule the next release

for around March/April next yr. Thoughts?

Andreas

pgpIoIUF7RJpI.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: Zope 3.2 maintenance

[Andreas Jung]

--On 8. September 2006 14:13:05 -0400 Tres Seaver <[EMAIL PROTECTED]> 
wrote:



  When you check in a bug fix, you almost always need to:

* Check in the fix on the current release branch


branches(!). For Zope 2 we actually maintain 2.10, 2.9 and still a bit 2.8.

-aj

pgp2jdg3pXfMa.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Testbrowser failure

[Andreas Jung]

--On 19. August 2006 17:25:39 +0530 Baiju M <[EMAIL PROTECTED]> wrote:





This is already fixed according to:
http://www.zope.org/Collectors/Zope3-dev/645

The fix is in 'ClientForm.py', this file is *not* set as an
svn:external in Zope 2.
Just setting this as svn:external to Zope 3.3 will fix this problem,
otherwise update this module.



Thanks, I copied over the file. Unfortunately svn:externals don't work on 
files but only on directories.


-aj

pgp8OKVxOs1qJ.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Testbrowser failure

[Andreas Jung]

Benji,

when running the Zope 2.10b2 unittests I see the following tests failing
(however this is not a blocker for the 2.10b2 release):

Failure in test test_strip_linebreaks_from_textarea (zope.testbrowser.tests)
Failed doctest test for 
zope.testbrowser.tests.test_strip_linebreaks_from_textarea
 File 
"/develop/sandboxes/Zope-2.10/2.10.0b2/lib/python/zope/testbrowser/tests.py", 
line 222, in test_strip_linebreaks_from_textarea


--
File 
"/develop/sandboxes/Zope-2.10/2.10.0b2/lib/python/zope/testbrowser/tests.py", 
line 245, in zope.testbrowser.tests.test_strip_linebreaks_from_textarea

Failed example:
   browser.getControl(name='textarea').value
Expected:
   'Foo\n'
Got:
   '\nFoo\n'
--
File 
"/develop/sandboxes/Zope-2.10/2.10.0b2/lib/python/zope/testbrowser/tests.py", 
line 263, in zope.testbrowser.tests.test_strip_linebreaks_from_textarea

Failed example:
   browser.getControl(name='textarea').value
Expected:
   '\nFoo\n'
Got:
   '\n\nFoo\n'


Andreas

--
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting


pgp0qwaTjdDF3.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository

[Andreas Jung]

--On 17. August 2006 01:11:44 -0400 Tres Seaver <[EMAIL PROTECTED]> 
wrote:


The appropriate thing here would be to remove the code which depends on
the GPL, and then ask the foundation's permission before readding it.
In the meanwhile, codespeak.net might provide a reasonable place from
which to continue development of said code.


That's extremly odd. Consider the following case: I am writing a ZPLed Zope 
product but include some migration shell scripts that call some common 
GPLed unix programs for a particular task...I wouldn't be allowed to 
checkin this
software on svn.zope.org? The advice to move the code out of the repository 
is not really legitimate. Neither rules as given through the contributor 
agreement nor unspoken rules were violated. Once again: using GPLed 
software does not make your own ZPLed software automatically GPLed.


-aj

pgpbHaCbPdq3z.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository

[Andreas Jung]

--On 16. August 2006 15:42:41 +0200 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:

Anyway, nothing is said about dependency on GPL-ed code. That's a
different debate. It's strictly not against rules, but it does mean one
expectation is broken: one might want to expect that all code in the
repository is freely usable without having to worry about GPL-provisions.
This is not the case for code that depends on GPL-ed code. Even though
this may be already a grey area for other reasons, it still makes sense
to think about the intent and people's expectations when checking in a
codebase.



I don't see any grey area. The purpose of cvs|svn.zope.org is to be a repos
for ZPLed software and the contributor agreement makes this purpose clear. 
But it was never the task of the repos to enforce a particular license - 
the ZPL - when building software with/on-top parts taken from 
svn|cvs.zope.org. It is up to the individual developers to take the 
software and use it under

the terms of the ZPL.


Andreas


pgpX6qn1fBH4R.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository

[Andreas Jung]

--On 16. August 2006 08:36:55 -0400 Benji York <[EMAIL PROTECTED]> wrote:


Jodok Batlogg wrote:

Log message for revision 69426:
  Initial import from Lovely Systems repository

Changed:
  A   lovely.rating/


This package appears to depend on GPLed software (schooltool,
specifically:
http://svn.zope.org/lovely.rating/trunk/src/lovely/rating/interfaces.py?r
ev=69429&view=markup)

I'm not sure it's appropriate to put it in the zope.org repo.


huh? The contributor agreement says nothing about external dependencies. As 
look as the checked-in code is ZPL, your software can depend on any other 
external package (independent of its license).


-aj

pgpOGZy7r6NA3.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] Should PageTemplate._text be a unicode or an encoded string in Zope 2.9.3?

[Andreas Jung]

--On 22. Juli 2006 16:17:09 +0200 Tino Wildenhain <[EMAIL PROTECTED]> 
wrote:

huh?..even on the file system a pt file is encoded using some encoding.
For an XML pagetemplate file the encoding is clearly defined through
the BOM (if available) and/or the XML preamble. So the most reliable
solution would be to use XML PTs only.


Yes but you have to explicitely store that information "somehow" in the
file - zope objects can use other methods to transfer encoding information
while they create the internal representation.
meta-tags for charset are quite ugly but you basically have no other
choice with filesystem stuff.
Problem here if the various encoding notifications collide (XML header
vs. XHTML meta-tag vs. BOM) so better have as few as possible - even
better none when


I am only talking of XML. And the encoding is clearly and unambiguously 
defined through the BOM (if available) and the XML preamble. So any 
application reading an XML file is able to detect the encoding and produce
a unicode string from the file. According to a discussion with Dieter the 
Python XML parsers don't deal with the BOM and leave it up to the 
application to interpret the BOM correctly.


-aj 

pgpcIJpK22Xkf.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] Should PageTemplate._text be a unicode or an encoded string in Zope 2.9.3?

[Andreas Jung]

--On 22. Juli 2006 15:34:01 +0200 Tino Wildenhain <[EMAIL PROTECTED]> 
wrote:

Well, pagetemplate files are another thing. They have to deal with
the lack of charset information of a filesystem file and what they
do once they load the data is even another thing.

Even filesystem pagetemplates should work with unicode internal,
making it easy to recode them for output and combine with other
potentially unicode stuff.



huh?..even on the file system a pt file is encoded using some encoding.
For an XML pagetemplate file the encoding is clearly defined through the 
BOM (if available) and/or the XML preamble. So the most reliable solution 
would be to use XML PTs only.


-aj

pgpfaEeT0wOes.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Zope 3.2.2 release?

[Andreas Jung]

Hi,

any chance for having a Zope 3.2.2 release this week? Since we are going to 
release Zope 2.9.4 soon, it would be really nice to have an official 3.2.2

release before.

Andreas

pgpSiQhdflnWl.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] The bug fixing problem

[Andreas Jung]

--On 16. Juli 2006 09:33:33 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote:


I'll note that *none* of the solutions include tests.   Tests are  often
the
bulk of the work.  A submitter should not assume that just because a
patch is provided, than someone only has to check it in.



Submitter do often provide unit tests if you gripe about the missing tests.
At least griping in the Zope 2 world worked out fine in the past :-)

-aj

pgpSNFRmFBpcW.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] State of Zope 3.3?

[Andreas Jung]

Hi,

could someone please summarize the current state of Zope 3.3? When can we 
produced with the next releases? We are currently running "a bit" late 
behind our original schedule :-)


Andreas

pgpCDQqRbcoyW.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?

[Andreas Jung]

--On 26. Juni 2006 11:25:05 +0100 Chris Withers <[EMAIL PROTECTED]> 
wrote:



Philipp von Weitershausen wrote:

It's dead from a maintenance point of view. If you still want to
maintain it, be our guest. But you yourself said that maintaining too
many branches is madness.


My point is that we're creating too many branches ;-)


Bascially 3 at this time. As I pointed out earlier it does not take too 
much effort e.g. to apply fixes to the 2.8 branch *as needed*.


Andreas

pgpptBSJWQq1z.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?

[Andreas Jung]

--On 19. Juni 2006 16:25:32 +0200 Lennart Regebro <[EMAIL PROTECTED]> wrote:



I for one, is NOT interested in backporting fixed in Five trunk to
both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current
versions of Five if we say that Zope 2.8 and 2.7 should be still
supported after the release of 2.10.


We don't talk about Zope 2.7 which is dead.

-aj

pgpxH1ETQngYX.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?

[Andreas Jung]

--On 18. Juni 2006 14:46:27 -0400 Christian Theune <[EMAIL PROTECTED]> wrote:


Andreas Jung wrote:



--On 18. Juni 2006 14:36:06 -0400 Christian Theune <[EMAIL PROTECTED]> wrote:

However, Zope 2.8 is still available for stable download ... so we
currently have 7 branches to watch out for.


Yes, but in most cases a fix only affects only Zope 2 or Zope 3. So
we are back to 3.


Right. 3 for each. And you do have to *think* whether a fix affects the
other one or not. That's the hard part, isn't it?


Of course we have to *think* but I think most cases are clear. Otherwise 
this belongs to the 0.12234724527% of the cases where you might break 
something...an element of risk remains


-aj



pgppSGSKKp6Yp.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?

[Andreas Jung]

--On 18. Juni 2006 14:35:48 -0400 Paul Winkler <[EMAIL PROTECTED]> wrote:


On Sun, Jun 18, 2006 at 08:30:58PM +0200, Lennart Regebro wrote:

On 6/18/06, Paul Winkler <[EMAIL PROTECTED]> wrote:
> +1, I'd like some way to easily know when a release is no longer
> maintained.  i.e., what's the X in the above formula.

Well, it's 2 versions, so far. I.e, current release and last release.
Unless we decide to change that now.


OK, but just to clarify:
Will we stop having to backport bugfixes to 2.8 when 2.10 final
is released?  But we need to backport bugfixes during the 2.10 beta
cycle?



My personal rule: if a fix/patch applies without a major effort to Zope 2.8 
than I will apply it (major effort means for me: some minutes). If a fix is 
important (whatever this means) I might invest some more time...but only 
speaking for myself. In edge cases we should decide from case to case.


Andreas

pgp5Ob65Pedxc.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?

[Andreas Jung]

--On 18. Juni 2006 14:36:06 -0400 Christian Theune <[EMAIL PROTECTED]> wrote:

However, Zope 2.8 is still available for stable download ... so we
currently have 7 branches to watch out for.


Yes, but in most cases a fix only affects only Zope 2 or Zope 3. So
we are back to 3.

-aj


--
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting


pgpIvbmC9paLN.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Zope 3.3.0 beta 1 released!

[Andreas Jung]

--On 9. Mai 2006 11:02:33 +0530 baiju m <[EMAIL PROTECTED]> wrote:


On 5/9/06, Stephan Richter <[EMAIL PROTECTED]> wrote:

Hello everyone,

The Zope 3 development team is proud to announce Zope 3.3.0 beta 1.


Congratulations to all worked behind this release!

I was trying to install this release using Python 2.5 alpha2
There was some warning like this from some modules :
  Warning: 'with' will become a reserved keyword in Python 2.6

Maybe substitute `with` with `with_`

And when I run server, there was another warning :
  /extra/Zope-3.3.0b1p25/lib/python/zope/configuration/config.py:184:
  DeprecationWarning: the gopherlib module is deprecated

Anyway this release is running in Python 2.5

Should I report this in collector?


Python 2.5 is not officially released and not offically not supported
and  not recommended for Zope 3. So stick with the supported versions.

-aj


--
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting


pgpLy6F8Jq7IA.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Zope and a RDB

[Andreas Jung]

--On 6. Mai 2006 10:12:21 +0200 John Catt <[EMAIL PROTECTED]> wrote:


Hello,

JSR 170

http://www.cmswatch.com/Feature/123
http://www.artima.com/lejava/articles/contentrepository3.html

seems to be the next standard of the CMS world.

Wouldn't be a good thing to make Zope 3 compatible with this standard ?



I think Nuxeo with its Zope 3 ECM project is working on JSR 170 support.
See z3lab.org.

-aj

--
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting


pgpr2HOwXPxRU.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] Reminder: Feature Freeze May 1

[Andreas Jung]

--On 21. April 2006 08:55:26 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote:



Don't forget that the feature freeze for the June release is May 1!
That is only 10 days away!  New features should be check in in a
*stable* form by then.  While we won't necessarily do a beta release
then, anything checked in for the new release must be ready for a
beta release when it is checked into the trunk.


We need agree on a release schedule. Perhaps we should agree on a schedule
on IRC?

Andreas

--
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting


pgpJJVcyZBBTW.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 14. März 2006 17:17:12 + Laurence Rowe <[EMAIL PROTECTED]> wrote:


I know that everyone here in pythonland seems to hate xml,


Nothing but a stupid rumor :-)


it may not be
pretty, but we have to use it for at least some things anyway. We
probably all spend quite a bit of our time writing xhtml, why not just
standardize on one format. Please, I don't want to learn any more
configuration languages.


Where is the effort for learning ZConfig or INI-style configuration when 
you

edit pre-configured zope.conf file?

-aj

pgp4wGdonGqDw.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 14. März 2006 07:27:54 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:



I have used schemas multiple times to represent hierarchies, most
recently in  the zf.zscp work, where I parse XML files using a schema or
a set thereof.  You simply use the Object field to connect a sub-schema
to a schema. I have  also used hierarchical schema trees in the
principal settings code, where you  hook in dynamically new schemas.


Exactly.



Assuming the fact that we could specify ZConfig-style and INI-style 
configuration files using nested zope.schemaswho is now the winner? :-)


-aj

pgpJaak8d7USs.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 14. März 2006 06:23:33 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:


Budding in:

It would be nice to be able to use Zope schema for
conversion and validation.  ZConfig was developed at
around the same time as Zope schema.  The ZConfig developers
fealt they couldn't wait and reuse the work on zope.schema.
and developed their own schema  system.  It sucks to have
to maintain 2.  It's also a pain for people who might want
to use ZConfig's to have to figure out another.  ZConfig
obviously "fits your brain". It doesn't fit mine at all.



Could you please explain how zope.schema would deal with hierarchies?
As I mentioned earlier the file format is uninteresting at this point.
Having an easy and flexible framework for defining a configuration schema
should be the goal and I have currently no idea how you would define
some more complex configuration schemas using zope.schema.

-aj


   -------
  -   Andreas JungZOPYX Ltd. & Co KG-
 -   E-mail: [EMAIL PROTECTED]   Web: www.zopyx.com, www.zopyx.de -
  ---


pgpOYKkAlIFTj.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Broken Tests

[Andreas Jung]

Date-Sent: 14. März 2006 07:45:59



--On 13. März 2006 16:49:27 -0500 Benji York <[EMAIL PROTECTED]> wrote:


It looks like revision 65953 ("updated to Docutils 0.4.0") broke the unit
tests.  For details see
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/b
uilds/382/test/0

Andreas, do you have any idea why that might be?


I fixed the problem in managerdetails. Docutils seems to perform tighter 
type checking. Since the reST adapter defines 'unicode' as input_encoding we
need to pass a unicode string (see managerdetails.py). The other problem is 
also already fixed.


Apart from that I did not receive and buildbot mails indicating the error.
Is there a problem with buildbot?

Andreas

pgp4plmz5xRm0.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Broken Tests

[Andreas Jung]

--On 13. März 2006 16:49:27 -0500 Benji York <[EMAIL PROTECTED]> wrote:


It looks like revision 65953 ("updated to Docutils 0.4.0") broke the unit
tests.  For details see
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/b
uilds/382/test/0

Andreas, do you have any idea why that might be?


I fixed the problem in managerdetails. Docutils seems to perform tighter 
type checking. Since the reST adapter defines 'unicode' as input_encoding we
need to pass a unicode string (see managerdetails.py). The other problem is 
also already fixed.


Apart from that I did not receive and buildbot mails indicating the error.
Is there a problem with buildbot?

Andreas

pgpWUTu51kWPM.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Moving to docutils 0.4.0?

[Andreas Jung]

I would like to update Docutils for Zope 2 trunk and Zope 3 trunk to v 
0.4.0.


Any objections for

- importing docutils as top-level module on svn.zope.org

- replacing src/docutils with an svn:externals definition

?

Andreas


pgpXIknsX6Wpy.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 9. März 2006 18:21:16 +0530 baiju m <[EMAIL PROTECTED]> wrote:


I don't know whether there is something for Zope, anyway just posting.
 http://groups.google.co.uk/group/turbogears/browse_thread/thread/f77979a
d0e1dacd0/b97cc6d6af9439d6?tvc=2&q=turbogears+configobj#b97cc6d6af9439d6

http://www.voidspace.org.uk/python/configobj.html




ugly and obscure.

-aj


pgp9DwP4Nf1Jn.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 7. März 2006 06:51:00 -0500 Chris McDonough <[EMAIL PROTECTED]> wrote:


My $.02:  I suspect it might be better to just use XML than  configparser
as a ZConfig replacement.  The config format is a  stretch under CP due
to the lack of hierarchy.  I'm beginning to  think the "don't make admins
use XML" argument should die.  Everybody  knows how to edit XML nowadays,
and if you need hierarchy, its  familiarity is tough to argue with.


XML as config format must die :-) ZConfig has the right balance between
a stupid INI format and XML.

The weak point at this discussion (as I mentioned earlier) is that we are 
discussion about a format and not about a flexible configuration framework
that solves the problems at ZConfig has. The format used at the end to feed 
the framework with data is pure syntactical sugar.


The idea to use schemas makes sense especially because schemas seem to 
provide everything you need right now. The only thing I have no clue about 
is how one would define hierachies through schemas (possibly through nested 
schemas)?


Writing a parser for some kind of INI format or ZConfig-style parser is an 
engineering task for an average programmer..I think we should discuss the 
framework and not a particular format (I agree with Dieter: it's unreadable

and only applicable to small configuration files).

-aj



pgpFDjuYpV0Op.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 5. März 2006 14:43:48 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:


 > There is no question that ZConfig has the

problems you described.  But I consider such a flat representation as
poor and a step back
instead of a step forward (independent of the effort needed to simply
and refactor ZConfig).


I agree, however, I think that there are other benefits of a move to
ConfigParser that far outweigh this disadvantage.



Let's try to approach from the other side. We both agree at ZConfig sucks 
at some point. We need something else. The "something else" should be 
provide

a similar functionality as ZConfig:

 - some support for hierarchies

 - schema-based

 - validation

 - default values

 - local configurations, no global schema

In the first place such a framework would be independent of any input 
format. A ZConfig-style parser or a .INI parser could use such a framework 
to make configuration information available through a unique API. So the 
basic "problem" of this whole issue is how such a framework would look 
like, how a schema-definition would look like etc. Writing a parser that 
adopts a particular input format to the abstract configuration framework is 
at best an engineering challenge and the decision to use a ZConfig-style or 
an INI-Style configuration file format as default is like a personal 
preference for beer or wine (beer for the mass, wine for the power users 
:-))


-aj



pgpzzcQaftHUO.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 5. März 2006 13:56:38 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:



The right way would be to refactor ZConfig and decouple it in a
reasonable way from its dependencies.


I think this would be a major rewrite.


Possibly but I don't consider that to be a strong argument for introducing
a weaker mechanism.>


They have to deal with it now, but now it's really hard.  I think that a
simpler
approach would allow much simpler configuration support.  To extend
ZConfig now,
you have to create XML schema descriptions, and have deep knowledge of how
ZConfig works.

Why do you think it's better to have to create a monolithic schema for all
applications bits that want to use the configuration file, rather than
letting
individual applications define how to read their own data independently?


A monolithic schema is of course a problem. I am sure it could be solved by 
refactoring ZConfig.




There could still be frameworks to make handling configuration data
easier.



I agree but I really dislike the idea of flattening a hierarchical 
structure
into a INI-like format. Having /x/y/z as section names looks both funny and 
somewhat unprofessional. The format looks as if would have been invented by 
a first grader. There is no question that ZConfig has the problems you 
described. But I consider such a flat representation as poor and a step back
instead of a step forward (independent of the effort needed to simply and 
refactor ZConfig).


-aj

pgpzRPpYccAEU.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration

[Andreas Jung]

--On 4. März 2006 21:26:30 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:



At:

   http://dev.zope.org/Zope3/UseConfigParserForHighLevelConfiguration

Is a proposal for using ConfigParser, rather than ZConfig for high-level
configuration.

Comments welcome.




-1

The right way would be to refactor ZConfig and decouple it in a reasonable 
way from its dependencies. ZConfig is a very smart module to define 
configurations and to verify configuration files. Replacing ZConfig with a 
very dumb format and moving more complexity (verification, argument 
conversion etc.= into the app layer is the wrong way. Apps should not have 
the need to deal with such low-level issues.


-aj



pgpGNV4s1KHzI.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: Two visions

[Andreas Jung]

--On 28. Februar 2006 16:06:55 +0100 Philipp von Weitershausen 
<[EMAIL PROTECTED]> wrote:


I think focusing on one app server and a dedicated set of libraries
would be a good alternative to two concurring app servers.




+1

-aj



pgp3JPYef1z8N.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope-dev] Re: [Zope3-dev] Two visions

[Andreas Jung]

--On 27. Februar 2006 21:57:46 -0500 Stephan Richter 
<[EMAIL PROTECTED]> wrote:



On Monday 27 February 2006 10:37, Jim Fulton wrote:

1) Our current vision (AFAIK) is that Zope 3 will eventually
   replace Zope 2

2) In an alternate vision, Zope 2 evolves to Zope 5.


As you probably know already, I am -1 on the second proposal, since it
will  disallow us to finally get rid of the old Zope 2 code.


Like it or not...I agree with Jim's vision will just be the reality. As 
long as we do support Zope 2 we will move more and more Z3 technology into 
Zope 2
which will strengthen Zope 2. I still do not see that Zope 3 will provide 
everything we need to build large-scale applications. Having CMF 2.0 and 
having some future Plone version running on top I don't see that Zope 2 
will fade out.


Andreas



pgpUc3AvCaf1Q.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: tal:define="..." considered harmful?

[Andreas Jung]

--On 12. Februar 2006 19:18:51 +0100 Max M <[EMAIL PROTECTED]> wrote:


Title


I could write this:

Title



That's really syntactical sugar. The purpose of the tal: names is clearly
to tell the parser to do _something_ with the value of an attribute. Now
should a parser guess if the value of an attribute is something to be 
processed or not? -1 for such ideas.


-aj



pgpfoecidL4qX.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Release schedule and deprecation decisions

[Andreas Jung]

--On 5. Februar 2006 12:11:08 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:



A while ago, we had some discussion on when to make releases and
how long to support deprecated features.  The discussion has died down
so I'll summarize what I think the conclusions were:

- We'll move releases up one month to may and November from June and
   December.  This means that the next release is scheduled for May and
   the next feature freeze is April 1.

- We will support deprecated features for 1 year.

I consider there to be decisions. :)



Also +1

-aj



pgpSOq50rodlE.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RFC: ZConfig and other formats for ZCML

[Andreas Jung]

--On 23. Januar 2006 15:22:27 -0500 Andrew Sawyers <[EMAIL PROTECTED]> 
wrote:



On Mon, 2006-01-23 at 18:51 +0100, Andreas Jung wrote:


This separation is artificial. I've never seen a single Zope
installation  where a system administrator had to care about Zope
configuration issue.  There was always a Zope developer in charge to
deal with configuration  issues.

Those of us developers who have been in this case might not like that to
always be the case.  :)  I'd like to live in a perfect World also.



Depends on the ratio developers : sysadmins. If it is 50:50 them the 
separation is ok. IMO it is 80:20 :-) But that's only my personal estimate.


-aj



pgpzixyUmWtwg.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RFC: ZConfig and other formats for ZCML

[Andreas Jung]

--On 23. Januar 2006 19:06:02 +0100 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:




Anyway, this whole discussion may be moot; Jim's proposal is rather hard
to interpret for people in this thread, so now I don't know anymore what
he's proposing. :)



I agree. I seconds Philipps proposal to simplify ZCML wherever possible
and to make it less verbose.

-aj

pgpMqxRvCzLMN.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RFC: ZConfig and other formats for ZCML

[Andreas Jung]

--On 23. Januar 2006 18:29:18 +0100 Martijn Faassen <[EMAIL PROTECTED]> 
wrote:

And the intended audience of ZCML is a very different audience -
developers versus sysadmins.



This separation is artificial. I've never seen a single Zope installation 
where a system administrator had to care about Zope configuration issue. 
There was always a Zope developer in charge to deal with configuration 
issues.


-aj

pgpxjpq6I6vAS.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] December release post-mortem

[Andreas Jung]

--On 18. Januar 2006 10:31:03 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:


Andreas Jung wrote:



...

The basic problem with the windows release is that there is currently
nobody in charge for the windows release (although Tim is again doing
working on the Windows side, ALL HAIL TIM).


I'll repeat or emphasis that the windows release process needs to
be simple enough that *I* can do it.


Well, that's a perfect goal :-) But my experience with doing slightly 
simple programming tasks on Windows is that Windows will slap you wherever 
possible - even when you're trying to solve simple problems. I stopped 
dreaming that anything on Windows works as it should.


just-being-a-frustrated-windows-hacker-(sometimes),
Andreas



pgpTf8XcFlc8o.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: [Zope-dev] December release post-mortem

[Andreas Jung]

--On 18. Januar 2006 07:36:35 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:



In the future, if someone introduces a major change, they *must* be
committed to be available to deal with issues that arise during the
release cycle.  Perhaps we need to pick different release dates to
avoid holidays.  Stephan has suggested moving the dates up to
November/May rather than December/June.


+1 for moving the dates. Speaking for the Zope 2 release:

- the zpkg chances were introduced very late and it was somewhat annoying
  to deal with this almost untested changes during the betas (not blaming
  Philipp here,  he has done a tremendous lot of work)

In addition such major changes should happen on a branch and not on the 
trunk and such changes should be started early before the next release (not 
week or two before the first beta).




And then there are the Windows releases.  Making Zope 2 windows releases
is very painful and there don't seem to be many people willing to help.
We've avoided the pain for Zope 3 by being less ambitious.  We let
distutils
do most of the work.  The result is that making a windows release takes
minutes
and is highly automated, but the experience for the end user is less than
ideal,  Many would rightfully argue that it is inadequate.  What we need
is a release process that is as easy as the Zope 3 windows release process
and produces a result as usable as the Zope 2 windows release.  I'm not
sure
exactly what the answer is, but I am sure we need to take a fresh
approach.
Whatever approach we take needs to be highly automated and must not
require
a lot of specialized Windows expertise.


The basic problem with the windows release is that there is currently
nobody in charge for the windows release (although Tim is again doing 
working on the Windows side, ALL HAIL TIM).






Note that I'm banking heavily on eggs without personally having worked
with
them much.  I'm very hopeful that we can make them work for us.

In the end, I consider the "December" release to be largely successful,
given
the challenges.


It was basically a birth with some pain :-)



These were some of my reactions to this first attempt at time-based
releases.
What do other folks think?


I think 2.9.0 is the _real_ 2.9 beta which will be widely used by ppl :-)


-aj

pgpCRLW9aQMe0.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES

[Andreas Jung]

--On 29. Dezember 2005 10:08:03 -0330 Rocky Burt <[EMAIL PROTECTED]> 
wrote:



Andreas Jung wrote:
 > Another argument against removing python expressions: in Zope 2

scripters could directly modify and test templates, script etc. (also
using the skins tool). In Z3 you have to restart the server at least for
view classes (but not for templates).


Personally I would say implement logic that allows view classes to be
reloadable rather than relying on zpt for exactly this reason if this is
indeed something developers need/want (I would love for such a feature).
 This was also one of the nice things about writing python scripts as a
skins item with CMF as it was instantly reloadable.



To bring it to the point: _scripters_ should be able to develop in Zope 3 
as easy as in Zope 2 :-)


-aj



pgpC5PO9Jq6U4.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] attr name space

[Andreas Jung]

--On 30. Dezember 2005 11:50:16 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:



I'm gonna stay out of this except to note that this discussion should
be happening on the ZPT list (zpt@zope.org), as it affects much more than
Zope 3 (or even Zope for that matter).



Wasn't the ZPT list considered obsolete some time ago?

-aj

pgp35d5UMHk2k.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com