Re: [Zope-dev] direction

2011-07-07 Thread Shane Hathaway
On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
 The ZMI is a highly insecure, completely outdated and user-unfriendly 
 interface.

As I read this, I got an idea for a possible way forward.  I haven't 
been reading zope-dev much lately, so forgive me if something like this 
has been mentioned already.

What if we had decorators that let us disable old code by default, yet 
allowed users to enable the old code with configuration?  Something like 
this:


import zope.oldcode

class SomeClass(SimpleObject):

 @zope.oldcode.zmi
 def manage_edit(self, REQUEST):
 # ...


The idea here is we'll create a zope.oldcode egg and fill it with 
decorators for pervasive features of Zope that need to be removed over 
time, such as the current ZMI.  We'll also create a configuration switch 
for each of those old features so that people can keep using them for a 
reasonable period of time.  When the zmi feature is disabled, the code 
above will replace the manage_edit method with a zope.oldcode.Disabled 
object that raises a helpful exception if anyone tries to call it.

It would also be good to make these decorators implement __nonzero__ to 
allow conditional attribute definition:

 if zope.oldcode.zmi:
 manage_properties = (...)

I would want to make sure conditional tests are possible as well:

 @zope.oldcode.zmi
 def test_manage_edit(self):
 # ...

(The zope.oldcode package probably ought to enable all old features by 
default when running tests.)

What do you think?

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-07 Thread Sylvain Viollon
On Tue, 5 Jul 2011 12:10:35 +0100
Laurence Rowe l...@lrowe.co.uk wrote:


  Hello,

 
 I agree with Jonas that any idea of giving a package named Zope2 a
 version number that is not 2.x is only going to lead to more
 confusion. For Zope2 we're used the x in 2.x.y being the major version
 now anyway, the next release should be 2.14. Lets stick with our
 convention until we have something that we really do want to promote
 to users outside the existing development community, I expect that
 will be a few years away yet.
 

  I fully agree with that. A major version of Zope 2 is actually a
  minor at the version meaning, but everybody knows that for instance
  to switch from 2.10 to 2.11 you have to review and update your code
  like if it was a real major version change at the version meaning.

  That would be really confusing to do otherwise, since it was like
  that for years.

  I am also in favor of dropping the 2, but picking a new name would
  be nice, like to have 'framework x' 10 that map to Zope 2 2.10,
  'framework x' to 2.11. Other products did that, Solaris,
  Mac OS X ... it is not strange to do so I think. 

  Regards,

  Sylvain,

-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-07 Thread Sylvain Viollon
On Tue, 5 Jul 2011 12:11:40 +0100
Martin Aspeli optilude+li...@gmail.com wrote:

 Hi,
 

  Hello,

 
 I think it would be very sad if that happened, especially since there
 evidently demand from other projects.
 
 What I think is clear is that to evolve Zope 2, we need to shed some
 baggage and make some deeper changes to allow us to achieve some of
 our goals (e.g. WSGI, simplified stack, simpler and more easily
 controllable security, less magical traversal, more comprehensible
 publisher).
 
 Plone is obviously a big consumer of Zope 2 and I would expect Plone
 to have a major influence on Zope 2's evolution. But ERP5 is another
 big consumer, and we shouldn't ignore that.
 
 

  And Silva.

  And maybe other companies that have a product and are not big enough
  to develop their product AND the framework they use.

  Regards,

  Sylvain



-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-07 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/07/2011 03:24 AM, Shane Hathaway wrote:
 On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
 The ZMI is a highly insecure, completely outdated and
 user-unfriendly interface.
 
 As I read this, I got an idea for a possible way forward.  I haven't
  been reading zope-dev much lately, so forgive me if something like
 this has been mentioned already.
 
 What if we had decorators that let us disable old code by default,
 yet allowed users to enable the old code with configuration?
 Something like this:
 
 
 import zope.oldcode
 
 class SomeClass(SimpleObject):
 
 @zope.oldcode.zmi def manage_edit(self, REQUEST): # ...
 
 
 The idea here is we'll create a zope.oldcode egg and fill it with 
 decorators for pervasive features of Zope that need to be removed
 over time, such as the current ZMI.  We'll also create a
 configuration switch for each of those old features so that people
 can keep using them for a reasonable period of time.  When the zmi
 feature is disabled, the code above will replace the manage_edit
 method with a zope.oldcode.Disabled object that raises a helpful
 exception if anyone tries to call it.
 
 It would also be good to make these decorators implement __nonzero__
 to allow conditional attribute definition:
 
 if zope.oldcode.zmi: manage_properties = (...)
 
 I would want to make sure conditional tests are possible as well:
 
 @zope.oldcode.zmi def test_manage_edit(self): # ...
 
 (The zope.oldcode package probably ought to enable all old features
 by default when running tests.)
 
 What do you think?

Neat -- sounds like an interesting thing to try a spike on, anyway.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4WLuwACgkQ+gerLs4ltQ46IgCgivBo8ucn91ix8YlsYknNG7HB
+fcAn2wyEQoKNNpZ+yv5OXHi9vKmtiHh
=Dm5a
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Laurence Rowe
On 5 July 2011 20:21, Leonardo Rochael Almeida leoroch...@gmail.com wrote:
 Hi Hanno,

 On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote:
 On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com 
 wrote:
 I would've thought it would also be possible for those who rely on this to
 maintain the relevant eggs as optional installations against Zope 2.x, no?

 The ZMI is not a package - we don't have a split into zope and
 zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates
 stops using RestrictedPython and the OFS base classes don't inherit
 from Acquisition.Implicit anymore, it'll be really hard to keep the
 legacy development approach working.

 I guess this is the biggest point of contention. Why does the ZMI have
 to go? Although both Plone and ERP5 strive to gradually replace ZMI
 based configuration with native interfaces (native to Plone/ERP5),
 isn't there value in having a minimal OFS browser with the ability to
 Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to
 conflict with your stated goal:

 I think what's going to stay is AccessControl, OFS (a bit lighter),
 ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of
 Zope Toolkit libraries like components, events, browser pages and so
 on.

 That's the kind of scope that should be possible to port to Python 3
 and actually modernize enough to be understandable.(...)

 Or to put it differently, in which way does having a minimalistic OFS
 browser for a ZMI conflicts or hinders Plone's objectives for the
 Zope2 code base?

 If we still have that minimalistic ZMI, all players in our community
 can decide how much effort they want to spend maintaining which legacy
 pieces technology, depending on what makes economic sense to them,
 without causing extra maintenance burden on the other players.

I think the problem with the current ZMI is that it brings in a whole
load of dependencies that we don't otherwise need - if it were
minimalistic it wouldn't be a problem. I'm all for someone writing a
very simple object browser though, it would make a great optional
package.

I'm certainly interested in moving away from OFS in the medium term
towards the much simpler ZTK / Pyramid approach of __getitem__
traversal.

Laurence
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Martijn Faassen
On 07/05/2011 12:22 PM, Jonas Meurer wrote:

 Since we don't market Zope2 anymore, I think there's actually much
 less confusion from this than we'd fear. It's just an internal version
 number used in some buildout files, not something that has any
 particular meaning.

 I don't like either of these solutions. And I don't agree with Hanno,
 that it's 'just an internal version number'. It will show up on
 zope.org, launchpad.net, and many more places.

 I would rather bump the version number to 2.20 to highlight the major
 changes, and keep the 2 as major for Zope2 versions.

I agree calling it Zope 2 version 3 would be very confusing. There's a 
lot of Zope 3 google juice around that would get muddled up even more.

Concerning not marketing Zope 2, heh, Zope and marketing strategies? I 
thought we were going to call Zope 2, Zope now, so people will 
obviously be curious about this Zope thing... Never make any assumptions 
about a coherent Zope marketing strategy! I'll also drop in a reference 
to the existence of zope2.zope.org.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Jens Vagelpohl
On 7/6/11 13:41 , Martijn Faassen wrote:
 Concerning not marketing Zope 2, heh, Zope and marketing strategies? I
 thought we were going to call Zope 2, Zope now, so people will
 obviously be curious about this Zope thing... Never make any assumptions
 about a coherent Zope marketing strategy! I'll also drop in a reference
 to the existence of zope2.zope.org.

I totally agree. Now would be a good moment to make it all a little 
better by dropping the name Zope 2 in favor of Zope. And I sincerely 
hope that zope2.zope.org will go away and its content end up on the 
new www.zope.org site.

jens

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Sascha Welter
I'm sorry, I don't really understand the current line of discussion yet.

I see a lot of discussion which part is going to be cut out and dropped,
or replaced. I haven't yet understood what's the end target for the
project.

So, are you guys expecting to get Zope into a shape where it will
attract new users and be a viable player again? Or, isn't the line
currently that nobody uses Zope for new projects anyway?

In case that we believe that no new users are attracted to Zope,
wouldn't that mean that resources should go to make Zope into a shape
that helps existing applications run on Zope and survive? Modernize the
code, but break as little as possible in the process. As someone said,
what's the use for a company that has invested a lot of money in a Zope
Product, if there is something called Zope around, but they can't use
it without a major rewrite?


In case all these changes are made to make Zope again into a shiny new
framework that will attract new users, what's the use? Wouldn't people
go to pyramid anyway? There they have all that stuff already - but right
*now*.

Looking at the descriptions here, in that line of thought and in the
long run we'll end up with something like pyramid in a few years, only
with a lot more disgruntled former users and much more confusion about
the name. When you change the name in the end, you've come full circle
anyway.

Regards,

Sascha

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Laurence Rowe
On 6 July 2011 15:27, Sascha Welter zopel...@betabug.ch wrote:
 I'm sorry, I don't really understand the current line of discussion yet.

 I see a lot of discussion which part is going to be cut out and dropped,
 or replaced. I haven't yet understood what's the end target for the
 project.

 So, are you guys expecting to get Zope into a shape where it will
 attract new users and be a viable player again? Or, isn't the line
 currently that nobody uses Zope for new projects anyway?

 In case that we believe that no new users are attracted to Zope,
 wouldn't that mean that resources should go to make Zope into a shape
 that helps existing applications run on Zope and survive? Modernize the
 code, but break as little as possible in the process. As someone said,
 what's the use for a company that has invested a lot of money in a Zope
 Product, if there is something called Zope around, but they can't use
 it without a major rewrite?


 In case all these changes are made to make Zope again into a shiny new
 framework that will attract new users, what's the use? Wouldn't people
 go to pyramid anyway? There they have all that stuff already - but right
 *now*.

 Looking at the descriptions here, in that line of thought and in the
 long run we'll end up with something like pyramid in a few years, only
 with a lot more disgruntled former users and much more confusion about
 the name. When you change the name in the end, you've come full circle
 anyway.

Zope in it's current form is not maintainable in the long run. There
are too many alternative ways of achieving the same thing. Over the
next few years we will need to start moving to Python 3, and the only
way to make that port possible is by reducing the size of the
codebase.

As a Plone developer, my interest is in how we make Zope into
something that enables Plone to continue evolving and developing, to
port to Python 3 and increasingly use more standard WSGI components.
Rewriting in Pyramid is not an option for us, large rewrites generally
fail (even if they do produce excellent new technology along the
way...)

Of course if people who have legacy applications want to continue
maintaining a 'Classic' Zope 2 in it's current form then they are free
to do so, but it won't happen without investment on their part. I
expect they will have similar concerns to the Plone developers, and
may find the same reduction and evolution approach to Zope useful.

Laurence
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Hanno Schlichting
Hi.

On Tue, Jul 5, 2011 at 9:21 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 I guess this is the biggest point of contention. Why does the ZMI have
 to go? Although both Plone and ERP5 strive to gradually replace ZMI
 based configuration with native interfaces (native to Plone/ERP5),
 isn't there value in having a minimal OFS browser with the ability to
 Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to
 conflict with your stated goal:

I think having a minimal database browser is a good idea. I think
something like https://github.com/davisagli/eye is the right starting
point here. I don't want to have anything that lives in the same
process as the rest of the application code. The ZMI is currently like
running phpMyAdmin accessible to the world with the same credentials
and on the same domain as the rest of your application. It's a huge
security risk and pollutes model classes and views in the application
code.

 Or to put it differently, in which way does having a minimalistic OFS
 browser for a ZMI conflicts or hinders Plone's objectives for the
 Zope2 code base?

The ZMI is a highly insecure, completely outdated and user-unfriendly interface.

On the security level, there's no validation of user-input, there's no
XSS and CSRF protection. Anyone being logged into your application who
has ZMI access is susceptible to a large number of attacks. There's
too much of stone-age code based on no-patterns to prevent these
attacks - we can currently only fix them in a tedious process of
finding one exploit after the other. We need a better strategy here -
and the only one I can see is removing the existing ZMI code and
moving any low-level interface to a completely separate codebase and
process.

On the other points, at least Plone tries to use modern web
technologies and for example we just switched to a HTML5 doctype -
having any end-user go to the ZMI and look at a frames-based interface
undermines any marketing message we try to put out about being modern.
And then the ZMI doesn't even do basic things like asking you for
confirmation before removing your entire site and being in almost all
regards a huge usability fail - again completely add odds with Plone's
good end-user usability story. On the code level the ZMI-support code
is mixed into all other model code and has often lead to arcane
developer API's. There's far too many places where a manage_* method
with a request argument is the only way to achieve anything. For
whatever code we'll end up with in two to three years, I want to see
good developer API's that actually make you productive.

I hope this clarifies a bit more, why I feel the ZMI is an arcane
beast that needs to be hunted down sooner than later.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@know-it.net wrote:
 OK, so you do think that we might use Zope 2.12 for a quite long time
 without thinking about anymore updates? Will there be any security
 updates for Zope 2.12 in the future?

You want to use Zope 2.13. 2.12 is at the end of its active
maintenance cycle as is Python 2.6 (the only Python version it
supports).

Zope 2.13 brings support for Python 2.7, which is a long-term
maintenance release.

How long Zope 2.13 is going to be supported and sees security fixes
will depend on the community. The Plone community will use it for its
4.1 and 4.2 releases, as a result of our security policy that should
result in us supporting Zope 2.13 for the next two years. Beyond that
nobody knows what will happen.

 Now i am completely shocked. We are building web applications for
 the last 6 years in Zope 2.x. All those applications are using the
 following techniques:

[snip]

What you are describing is exactly what I meant by old legacy Zope2
applications.

You should be able to use this style of development with Zope 2.13.
But you won't be able to upgrade to newer versions of Zope 2 anymore
and expect your code to work unmodified. We discouraged this style of
development for the past six years. It should come as no surprise that
it will come to an end at some point.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Mon, Jul 4, 2011 at 10:49 AM, Sylvain Viollon sylv...@infrae.com wrote:
  ... and I still do use the VirtualHostMonster
  (you can trash all the other things).

  I agree that its code might not been the best in the world, but it
  works for the moment and does what it says (I would love to see
  shiftNameToApplication implemented with more than one pass).

Ok. I didn't mean to remove the VHM at any point. I removed it from
the default content over the weekend but given its popularity, I think
I can safely put it back.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Martin Aspeli
On 5 July 2011 09:42, Hanno Schlichting ha...@hannosch.eu wrote:

 What you are describing is exactly what I meant by old legacy Zope2
 applications.

 You should be able to use this style of development with Zope 2.13.
 But you won't be able to upgrade to newer versions of Zope 2 anymore
 and expect your code to work unmodified. We discouraged this style of
 development for the past six years. It should come as no surprise that
 it will come to an end at some point.


I would've thought it would also be possible for those who rely on this to
maintain the relevant eggs as optional installations against Zope 2.x, no?

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com wrote:
 I would've thought it would also be possible for those who rely on this to
 maintain the relevant eggs as optional installations against Zope 2.x, no?

The ZMI is not a package - we don't have a split into zope and
zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates
stops using RestrictedPython and the OFS base classes don't inherit
from Acquisition.Implicit anymore, it'll be really hard to keep the
legacy development approach working.

Someone might try, but I think it's not a wise decision to spent any
resources that way. At some point every application written in the
legacy style has to be rewritten. I think it would be a better use of
resources for anyone to start doing that than maintaining a dead-end.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Martin Aspeli
On 5 July 2011 10:18, Hanno Schlichting ha...@hannosch.eu wrote:

 On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com
 wrote:
  I would've thought it would also be possible for those who rely on this
 to
  maintain the relevant eggs as optional installations against Zope 2.x,
 no?

 The ZMI is not a package - we don't have a split into zope and
 zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates
 stops using RestrictedPython and the OFS base classes don't inherit
 from Acquisition.Implicit anymore, it'll be really hard to keep the
 legacy development approach working.


I think it might be useful to spell out the reasons behind this (here, or
better yet, somewhere more permanent like zope.org). I can imagine people
reading this and wondering why it's a good idea, especially those who have
an investment in the existing technologies.


 Someone might try, but I think it's not a wise decision to spent any
 resources that way. At some point every application written in the
 legacy style has to be rewritten. I think it would be a better use of
 resources for anyone to start doing that than maintaining a dead-end.


This is a pretty sweeping statement that I think could cause a lot of
nervousness. It might be the right thing in many ways, but we need to at
least provide a bit more context. If you're a business that's invested
dozens of person-years into a product, the prospect of rewriting could seem
fairly daunting. At least we, as the Zope 2 community, need to set out the
case for change and some kind of idea of timing and transition path, even if
that means in some cases getting to a long term maintenance release and in
other cases evolving away from certain technologies whilst being confident
to keep using others.

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Mon, Jul 4, 2011 at 12:19 PM, yuppie y.2...@wcm-solutions.de wrote:
 Long-term maintenance for Zope 2.13 would give these
 projects/deployments at least a few more years.

Yes. I'm willing to cut releases for it for quite a while. I just
expect to see active maintenance from the Plone community to stop in a
year or two. Judging from the ongoing maintenance we currently have
for Zope 2.10 or 2.11 I don't think it's very realistic to expect much
to happen once the Plone guys stop.

 What I'm outlining here has of course almost nothing to do with the
 original idea and scope of Zope 2. Maybe at some point this should get
 a different name ;-)

 I don't want to discuss names, but I think the next release from Zope
 trunk should be explicitly a new *major* release.

I think that's perfectly fine. Since I broke backwards compatibility
with a number of changes I did, a major version increase is warranted.

So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
5.0 or anything else doesn't make it any better at all. So 3.0 is the
most sensible one :)

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Martin Aspeli
On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote:

 On Mon, Jul 4, 2011 at 12:19 PM, yuppie y.2...@wcm-solutions.de wrote:
  Long-term maintenance for Zope 2.13 would give these
  projects/deployments at least a few more years.

 Yes. I'm willing to cut releases for it for quite a while. I just
 expect to see active maintenance from the Plone community to stop in a
 year or two. Judging from the ongoing maintenance we currently have
 for Zope 2.10 or 2.11 I don't think it's very realistic to expect much
 to happen once the Plone guys stop.

  What I'm outlining here has of course almost nothing to do with the
  original idea and scope of Zope 2. Maybe at some point this should get
  a different name ;-)
 
  I don't want to discuss names, but I think the next release from Zope
  trunk should be explicitly a new *major* release.

 I think that's perfectly fine. Since I broke backwards compatibility
 with a number of changes I did, a major version increase is warranted.

 So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
 5.0 or anything else doesn't make it any better at all. So 3.0 is the
 most sensible one :)


Boy, that's going to be confusing. :)

I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
defunct Zope 3, although I don't think there are any particularly good
options here.

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote:
 On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote:
 So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
 5.0 or anything else doesn't make it any better at all. So 3.0 is the
 most sensible one :)

 Boy, that's going to be confusing. :)
 I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
 defunct Zope 3, although I don't think there are any particularly good
 options here.

Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this.
That's as confusing as anything else and would lead to the question
what happened to Zope2 3.0.

Since we don't market Zope2 anymore, I think there's actually much
less confusion from this than we'd fear. It's just an internal version
number used in some buildout files, not something that has any
particular meaning.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Jens Vagelpohl
On 7/5/11 11:56 , Martin Aspeli wrote:
 On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.eu  wrote:
 So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
 5.0 or anything else doesn't make it any better at all. So 3.0 is the
 most sensible one :)


 Boy, that's going to be confusing. :)

 I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
 defunct Zope 3, although I don't think there are any particularly good
 options here.

I actually think it's a brilliant idea to skip 3.0 and call it 4.0.

As Martin said, the potential for confusion is very high. A 4.0 would 
not only steer around confusing Zope3 3.x and Zope2 3.x, it would also 
make it easier to move back to the simple Zope moniker without any 
qualifying number tacked on. People who only look at version numbers 
would now choose Zope 4.0 instead of falling into the unmaintained 
Zope3 trap.

jens

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Martin Aspeli
On 5 July 2011 11:10, Jens Vagelpohl j...@dataflake.org wrote:

 On 7/5/11 11:56 , Martin Aspeli wrote:
  On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.eu  wrote:
  So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
  5.0 or anything else doesn't make it any better at all. So 3.0 is the
  most sensible one :)
 
 
  Boy, that's going to be confusing. :)
 
  I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with
 the
  defunct Zope 3, although I don't think there are any particularly good
  options here.

 I actually think it's a brilliant idea to skip 3.0 and call it 4.0.

 As Martin said, the potential for confusion is very high. A 4.0 would
 not only steer around confusing Zope3 3.x and Zope2 3.x, it would also
 make it easier to move back to the simple Zope moniker without any
 qualifying number tacked on. People who only look at version numbers
 would now choose Zope 4.0 instead of falling into the unmaintained
 Zope3 trap.


I would tend to agree, given that we now have Blue Bream.

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Jonas Meurer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 05.07.2011 12:04, schrieb Hanno Schlichting:
 On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com 
 wrote:
 On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote:
 So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
 5.0 or anything else doesn't make it any better at all. So 3.0 is the
 most sensible one :)

 Boy, that's going to be confusing. :)
 I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
 defunct Zope 3, although I don't think there are any particularly good
 options here.
 
 Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this.
 That's as confusing as anything else and would lead to the question
 what happened to Zope2 3.0.
 
 Since we don't market Zope2 anymore, I think there's actually much
 less confusion from this than we'd fear. It's just an internal version
 number used in some buildout files, not something that has any
 particular meaning.

I don't like either of these solutions. And I don't agree with Hanno,
that it's 'just an internal version number'. It will show up on
zope.org, launchpad.net, and many more places.

I would rather bump the version number to 2.20 to highlight the major
changes, and keep the 2 as major for Zope2 versions.

Greetings,
 jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOEuXYAAoJEFJi5/9JEEn+JS0QALwzhuqnNvVzngKpEiDRIPmG
SIbAlbvUHIOb15kZCWCZlJjvmIuwHd2eQdbKScit7o/WBNzH38L5+BGoWPZil0k6
X04WmaXd/15OfWtGGkwsxG8Jt9gO5b6kvyu9a54qVdiNpHs9M5531XvCcPFyG9yY
FLdmkRUMtpATg7o0YLt2B5lKWnojDvVvVgTXy8ad/UhO6TKrNzySRHLPiOhnh9LY
7axX/ExErzU9CFPB02joKP140ex5Om72L66FXWVNNZ9GUVaIT0puOTxLnbfkSahl
TeItFjzby4xdQ89ot5OD7nlMgvuPx0Scstuf+GaQH60xoTDj8EIQEwoSotDYMUSD
GHqD3eGsn1ORgB2ov/7dUW9xaEkLHfu7ikLozGXnD2xtGXTZG7tjuagmusV9Mftj
kRjoCrSAAz8KM4FnAeLxdgYHIIEN3KRkJXeyqAMtcOoCgRZFEWILJWxcoU2CbYP9
4WAeQlnWby5KgUS+rSiJ7zLRu0uas4gAKb513jt1KJDOFSmzVQECrpQJ3bHvykK7
uVj+00/smgPk/DnCLlJTHuZwQVDEFmAtjOd31lreTHAFE46BHmbjSYMFXIHI01D4
4H4AiXlnb2BS55wH+JvmdM1+j8IkgaBI6LBtBCotpcZXSAv4/BXvCm2Ynwte/yXU
GlwhHtBmyZ6HfdhuVrUI
=Cir1
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Tobias Helfrich

Hi Hanno 

 On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich 
 helfr...@know-it.net wrote:
  OK, so you do think that we might use Zope 2.12 for a quite 
 long time 
  without thinking about anymore updates? Will there be any security 
  updates for Zope 2.12 in the future?
 
 You want to use Zope 2.13. 2.12 is at the end of its active 
 maintenance cycle as is Python 2.6 (the only Python version 
 it supports).
 
 Zope 2.13 brings support for Python 2.7, which is a long-term 
 maintenance release.

OK, thx for the info. So we will be able to use Zope 2.13 with the 
techniques mentioned before? That will give us another two years to 
think about going on with different styles. So basically Zope 2 will 
be the framework for Plone only, because the community which is/was 
using Zope 2 for standalone individual projects has decreased to nearly 
none. So it might be a good idea to look for something completely 
different? I don't think that Plone will be able to do everything we 
want it to. Or do you think we can stick with Zope 2 but change the way 
of building applications to ZPT/TAL? So we have to get rid of all DTML 
and what about an alternative to the ZSQL Methods?

 
 How long Zope 2.13 is going to be supported and sees security 
 fixes will depend on the community. The Plone community will 
 use it for its
 4.1 and 4.2 releases, as a result of our security policy that 
 should result in us supporting Zope 2.13 for the next two 
 years. Beyond that nobody knows what will happen.

I do agree.

 
  Now i am completely shocked. We are building web 
 applications for the 
  last 6 years in Zope 2.x. All those applications are using the 
  following techniques:
 
 [snip]
 
 What you are describing is exactly what I meant by old legacy 
 Zope2 applications.
 
 You should be able to use this style of development with Zope 2.13.
 But you won't be able to upgrade to newer versions of Zope 2 
 anymore and expect your code to work unmodified. We 
 discouraged this style of development for the past six years. 
 It should come as no surprise that it will come to an end at 
 some point.

OK, i have subscribed to the mailing list today, so unfortunately 
i haven't found this sort of information anywhere else. I don't want 
to blame you or anyone else for that, but it's not nice to hear that 
right now :-(
It might has been too confusing in the past, with Zope 3 being such 
a mistake and of course i haven't really checked whether to change 
something or not...

 
 Hanno
 

Toby
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Jonas Meurer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 05.07.2011 11:30, schrieb Martin Aspeli:
 
 
 On 5 July 2011 10:18, Hanno Schlichting ha...@hannosch.eu
 mailto:ha...@hannosch.eu wrote:
 
 On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli
 optilude+li...@gmail.com mailto:optilude%2bli...@gmail.com wrote:
  I would've thought it would also be possible for those who rely on
 this to
  maintain the relevant eggs as optional installations against Zope
 2.x, no?
 
 The ZMI is not a package - we don't have a split into zope and
 zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates
 stops using RestrictedPython and the OFS base classes don't inherit
 from Acquisition.Implicit anymore, it'll be really hard to keep the
 legacy development approach working.
 
 
 I think it might be useful to spell out the reasons behind this (here,
 or better yet, somewhere more permanent like zope.org
 http://zope.org). I can imagine people reading this and wondering why
 it's a good idea, especially those who have an investment in the
 existing technologies.
  
 
 Someone might try, but I think it's not a wise decision to spent any
 resources that way. At some point every application written in the
 legacy style has to be rewritten. I think it would be a better use of
 resources for anyone to start doing that than maintaining a dead-end.
 
 
 This is a pretty sweeping statement that I think could cause a lot of
 nervousness. It might be the right thing in many ways, but we need to at
 least provide a bit more context. If you're a business that's invested
 dozens of person-years into a product, the prospect of rewriting could
 seem fairly daunting. At least we, as the Zope 2 community, need to set
 out the case for change and some kind of idea of timing and transition
 path, even if that means in some cases getting to a long term
 maintenance release and in other cases evolving away from certain
 technologies whilst being confident to keep using others.

I agree with Martin, that a sane upgrade path should be provided at
least. If people still use things like DTML, the ZMI, etc., then it
would be highly frustrating for them to simply drop these.

You can split the components from the base and provide them as optional
where possible. This seems to be possible with most of the components
that Hanno listed as depreciated/to be removed soon.

And most importantly: provide sane upgrade paths for depreciated
components. If the ancient session management from Zope2 is to be
dropped, tell people what they should use instead, and how to migrate
their old_but_still_in_use applications/projects.

Greetings,
 jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOEudWAAoJEFJi5/9JEEn+jXcP/RyNZw1JFfPqG/nzacqAbx4F
WdoZGyARkGVV1BTEtE6/cvkJCnHNuBgEaeAtGJY7h5HdqT781uKNdhJurncA8ii3
7RXm0CVJ1AZXdycDT0DoOMyYWBx345cglk5S+5bbfIdMWVvPNyDgQhIjFRT20jA7
cMi8e4mStgd2upwS487L+FubmkWyOw8d8bUbL+SFvykNOEXr6OqwTHLTBWh4yVi3
//zmV6T/wtmcpIyiqdx4VkdvmmttJbM2ro0FcIvO46XHD87XrYSiyEZM3XiYsjiF
8hNqhHtkiA/mLRXw6jIDhMvzvIsgKsWdHMmR2OOGVPY5nnWuvmBimaSj+u01TJIS
K1MLMNnheTqH7alr7Mn0PmIGfbX4ED9DwzrR2yen6iHmWqgHShDC+OAFrRzFBK51
fPnLlAVQrQSDLPhhm+Ytv55o/hzmzARUUnta4d+Ac2k0y/DLXuz+8svSdfLuKVyv
0W5onVnLuXH5z5X3HM5ubywUdyfOaVgCIYdV+vVh9tQCeLZsDN6rVl+4H5WCQuNk
J17+m4B59zAxAhIxa0ZwnLHVwO+GgP+pIHhQtSZGF1WY43wBFPDxKtt8xxBCjPvk
LyMPgevwTn4rhETwkCsZFqMvVGBa/AmKX3suQhNBNFr+8qOy/H/q4tOQGpUyBmNE
nVJtAfGh/G+ecROUKMAW
=eItl
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Laurence Rowe
On 5 July 2011 11:22, Jonas Meurer jo...@freesources.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 05.07.2011 12:04, schrieb Hanno Schlichting:
 On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com 
 wrote:
 On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote:
 So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or
 5.0 or anything else doesn't make it any better at all. So 3.0 is the
 most sensible one :)

 Boy, that's going to be confusing. :)
 I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
 defunct Zope 3, although I don't think there are any particularly good
 options here.

 Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this.
 That's as confusing as anything else and would lead to the question
 what happened to Zope2 3.0.

 Since we don't market Zope2 anymore, I think there's actually much
 less confusion from this than we'd fear. It's just an internal version
 number used in some buildout files, not something that has any
 particular meaning.

 I don't like either of these solutions. And I don't agree with Hanno,
 that it's 'just an internal version number'. It will show up on
 zope.org, launchpad.net, and many more places.

 I would rather bump the version number to 2.20 to highlight the major
 changes, and keep the 2 as major for Zope2 versions.

I agree with Jonas that any idea of giving a package named Zope2 a
version number that is not 2.x is only going to lead to more
confusion. For Zope2 we're used the x in 2.x.y being the major version
now anyway, the next release should be 2.14. Lets stick with our
convention until we have something that we really do want to promote
to users outside the existing development community, I expect that
will be a few years away yet.

Laurence
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Martin Aspeli
Hi,

On 5 July 2011 11:26, Tobias Helfrich helfr...@know-it.net wrote:


 Hi Hanno

  On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich
  helfr...@know-it.net wrote:
   OK, so you do think that we might use Zope 2.12 for a quite
  long time
   without thinking about anymore updates? Will there be any security
   updates for Zope 2.12 in the future?
 
  You want to use Zope 2.13. 2.12 is at the end of its active
  maintenance cycle as is Python 2.6 (the only Python version
  it supports).
 
  Zope 2.13 brings support for Python 2.7, which is a long-term
  maintenance release.

 OK, thx for the info. So we will be able to use Zope 2.13 with the
 techniques mentioned before? That will give us another two years to
 think about going on with different styles. So basically Zope 2 will
 be the framework for Plone only, because the community which is/was
 using Zope 2 for standalone individual projects has decreased to nearly
 none.


I think it would be very sad if that happened, especially since there
evidently demand from other projects.

What I think is clear is that to evolve Zope 2, we need to shed some baggage
and make some deeper changes to allow us to achieve some of our goals (e.g.
WSGI, simplified stack, simpler and more easily controllable security, less
magical traversal, more comprehensible publisher).

Plone is obviously a big consumer of Zope 2 and I would expect Plone to have
a major influence on Zope 2's evolution. But ERP5 is another big consumer,
and we shouldn't ignore that.


 So it might be a good idea to look for something completely
 different? I don't think that Plone will be able to do everything we
 want it to. Or do you think we can stick with Zope 2 but change the way
 of building applications to ZPT/TAL? So we have to get rid of all DTML
 and what about an alternative to the ZSQL Methods?


I think keeping DTML as an optional installation should be quite feasible.
It's just possibly not something that the core Zope 2 team want to maintain
anymore in the standard distribution.

ZSQL Methods may be a similar story, in fact, especially as they rely on
DTML. However, I'd encourage you to look at SQLAlchemy, which is way nicer
to work with.


 OK, i have subscribed to the mailing list today, so unfortunately
 i haven't found this sort of information anywhere else. I don't want
 to blame you or anyone else for that, but it's not nice to hear that
 right now :-(


I think there is some characteristic bluntness in Hanno's emails, but please
realise that none of this is going to happen over night, and existing
codebases are not going to magically disappear. Sometimes we have to be a
bit more radical to understand the art of the possible and build a future
platform that will support future needs. That doesn't mean there can't be
both migration paths and long-term stable versions.

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohl j...@dataflake.org wrote:
 On 7/5/11 11:56 , Martin Aspeli wrote:
 On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.eu  wrote:
 I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
 defunct Zope 3, although I don't think there are any particularly good
 options here.

 I actually think it's a brilliant idea to skip 3.0 and call it 4.0.

Ok, seems 4.0 is the more popular choice.

We'll use that than and make Tres proud
(http://www.palladion.com/home/tseaver/obzervationz/2009/zope-4.0-project
- though zopefour.org has been taken over by a link farm).

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Jens Vagelpohl
On 7/5/11 14:41 , Hanno Schlichting wrote:
 On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohlj...@dataflake.org  wrote:
 On 7/5/11 11:56 , Martin Aspeli wrote:
 On 5 July 2011 10:31, Hanno Schlichtingha...@hannosch.euwrote:
 I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the
 defunct Zope 3, although I don't think there are any particularly good
 options here.
 I actually think it's a brilliant idea to skip 3.0 and call it 4.0.

 Ok, seems 4.0 is the more popular choice.

 We'll use that than and make Tres proud
 (http://www.palladion.com/home/tseaver/obzervationz/2009/zope-4.0-project
 - though zopefour.org has been taken over by a link farm).

zopefour as a domain isn't very helpful. It would add yet another 
top-level name to the existing list (Zope 2, Zope 3).

In the best of all possible worlds the package now known as Zope2 
would simply be Zope, and its website is at www.zope.org. Zope is 
making the jump from version 2.x to 4.0.

jens


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Charlie Clark
Am 05.07.2011, 14:44 Uhr, schrieb Jens Vagelpohl j...@dataflake.org:

 zopefour as a domain isn't very helpful. It would add yet another
 top-level name to the existing list (Zope 2, Zope 3).
 In the best of all possible worlds the package now known as Zope2
 would simply be Zope, and its website is at www.zope.org. Zope is
 making the jump from version 2.x to 4.0.

+1

Logically Zope 2.12 would have been a major release due to eggification  
and dropping Python 2.4. Only makes sense to make label the next major  
version as such rather than pretending with 2.x that only minor changes  
are being made.

As I've been able to do little or no development this year thanks to  
Leonardo for raising this and Hanno for his explanation. I do think a  
public roadmap, with opportunities for people wanting to get involved  
would be a good idea.

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Hanno Schlichting
On Tue, Jul 5, 2011 at 2:44 PM, Jens Vagelpohl j...@dataflake.org wrote:
 zopefour as a domain isn't very helpful. It would add yet another
 top-level name to the existing list (Zope 2, Zope 3).

That was an April fools joke I was referring to. I didn't mean to
suggest to actually use that in any way ;-)

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Martijn Pieters
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting ha...@hannosch.eu wrote:
 Ok, seems 4.0 is the more popular choice.

I don't agree. Let's go with Fibonacci and call the next release Zope
8, as the logical extension of the series 1, 2, 3, and 5!

:-P

-- 
Martijn Pieters
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Andreas Jung



Martijn Pieters wrote:

On Tue, Jul 5, 2011 at 14:41, Hanno Schlichtingha...@hannosch.eu  wrote:

Ok, seems 4.0 is the more popular choice.


I don't agree. Let's go with Fibonacci and call the next release Zope
8, as the logical extension of the series 1, 2, 3, and 5!


How about

ZopeNG?

Waiting-for-some-beating,
Andreas
attachment: lists.vcf___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Christopher Lozinski
On 7/5/11 3:22 AM, zope-dev-requ...@zope.org wrote:

Hanno writes:
 Someone might try, but I think it's not a wise decision to spent any
 resources that way. 
 
I am trying.  I am trying to create a Zope 2 like TTW development
environment on top of BlueBream.  I have a small email list of people
who see the world this way.  While many core ZTK developers do not like
TTW development, there are many of us zope users who do like it.  May a
thousand open-source flowers bloom. 

I am making progress.  I have ice.control and ZAM running.  I have the
ZMI running on Zope 3.something.But I am finding it very hard
work.I learned quite a bit from this discussion, thank you.   All I
have to do is subclass the OFS with something that also inherits from
acquisition.  Cool.  And then integrate all the ZMI code into ZAM.  Then
get the rest of the content types working. 

I am stuck on figuring out which page template in ZAM to edit.  And I am
stuck on figuring out how to fire up the ZMI in Bluebream.  I will
figure it all out.Or I will hire some of the Bluebream guys in
eastern Europe to help me figure it out.  In any case I now have a
project that needs it, so I am motivated.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and TouchTexting
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Leonardo Rochael Almeida
Hi Hanno,

On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote:
 On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com 
 wrote:
 I would've thought it would also be possible for those who rely on this to
 maintain the relevant eggs as optional installations against Zope 2.x, no?

 The ZMI is not a package - we don't have a split into zope and
 zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates
 stops using RestrictedPython and the OFS base classes don't inherit
 from Acquisition.Implicit anymore, it'll be really hard to keep the
 legacy development approach working.

I guess this is the biggest point of contention. Why does the ZMI have
to go? Although both Plone and ERP5 strive to gradually replace ZMI
based configuration with native interfaces (native to Plone/ERP5),
isn't there value in having a minimal OFS browser with the ability to
Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to
conflict with your stated goal:

I think what's going to stay is AccessControl, OFS (a bit lighter),
ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of
Zope Toolkit libraries like components, events, browser pages and so
on.

That's the kind of scope that should be possible to port to Python 3
and actually modernize enough to be understandable.(...)

Or to put it differently, in which way does having a minimalistic OFS
browser for a ZMI conflicts or hinders Plone's objectives for the
Zope2 code base?

If we still have that minimalistic ZMI, all players in our community
can decide how much effort they want to spend maintaining which legacy
pieces technology, depending on what makes economic sense to them,
without causing extra maintenance burden on the other players.

 [...]

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread Sylvain Viollon
On Sun, 03 Jul 2011 01:09:17 -0400
Chris McDonough chr...@plope.com wrote:

 On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote:
 

  Hello,

  - Continue to remove functionality tailored for TTW development,
  like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
  - Document and use the WSGI publisher and remove obsoleted
  functionality like the virtual host monster, error_log,
  ZServer/medusa, zopectl/zdaemon
 
 Zope still needs to the virtual host monster (or something like it)
 even with the WSGI publisher; there's nothing equivalent in the WSGI
 world (unless you could repoze.vhm, which is essentially just the
 virtual host monster, and probably doesn't need to live in
 middleware; no one uses it except people who use repoze.zope2).
 

  I have my own WSGI implementation, since a while, that works
  perfectly (infrae.wsgi), and I still do use the VirtualHostMonster
  (you can trash all the other things).

  I agree that its code might not been the best in the world, but it
  works for the moment and does what it says (I would love to see
  shiftNameToApplication implemented with more than one pass).

  I will sad to learn that this goes away, if nothing replace it. I
  kind of don't like the WSGI approach of cutting the database,
  traversing, authorization, rewriting Zope 2 concepts into middleware
  as I think they don't really fit the design of pipes provided by the
  WSGI middleware concept (but I do use middlewares for other things
  with Zope 2).

  - Make the browser id manager, session data manager, temporary
  storage optional and remove it and request.SESSION from the core,
  instead we can use something based on
  Products.BeakerSessionDataManager / collective.beaker if someone
  has a need for sessions
 
 I don't have any skin in this game, but FTR, Mike Bayer isn't feeling
 all that confident about Beaker's sessioning component (or so he has
 told me).  Beaker was originally made as a caching component, and had
 sessioning jammed into it quite late; nobody is really maintaining the
 sessioning component of it now.
 

  I don't use the request.SESSION since a long time (as they are slow
  and badly designed in Zope 2 I think), and use beaker as a storage
  for the session (because it is highly configurable). However I don't
  directly use the session mechanism of beaker either, and I would
  agree with Mike Bayer.

  I find the beaker code messy and confusing, it sounds like it started
  simple, and lot of feature have been added to support everything,
  with backward compatibility up to the first version. And when you
  have a bug to look for, it is kind of spaghetti code. If that remind
  you an another project :).

  Regards,

  Sylvain,

-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread Marius Gedminas
On Sun, Jul 03, 2011 at 06:10:48PM +0200, Wichert Akkerman wrote:
 On 2011-7-3 17:48, Martin Aspeli wrote:
  FWIW, we have a high-performance, high-load application in production on
  Plone 4 with collective.beaker relying heavily on sessions, and I'm not
  aware of any problems with it. We use the memcached backend across two
  physical servers and a large number of Zope clients.
 
 In my experience it depends highly on the memcache client library you 
 use with beaker. With some the results are disastrous, with other it is 
 stable. Where possible I have switched to cookie-based sessions to 
 prevent stability problems.

Aren't all sessions cookie-based?

Did you mean you switched to secure cookies instead of server-side state?

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3/BlueBream consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread yuppie
Hi!


Hanno Schlichting wrote:
 I think moving to Zope 2.12 and 2.13 does have some value for Nexedi
 or other large existing codebases, as you get support for current
 versions of the ZODB, Zope Toolkit packages and support for Python 2.7
 with Zope 2.13. Since Python 2.7 is a long-term maintenance release
 for Python itself, this should provide a stable and good basis for the
 next years - the statements from the Python community aren't
 completely clear - but I'd expect to see ongoing maintenance until
 2013 or maybe even 2015.

With the big changes you propose for Zope 2, some existing 
projects/deployments will stay stuck with Zope 2.13 (or Zope 2.X if Zope 
trunk is not released as Zope 2.14).

Long-term maintenance for Zope 2.13 would give these 
projects/deployments at least a few more years.

 Going forward I can see two paths for Zope 2. Either we don't touch it
 at all anymore and let it bitrot or we try to move it forward and
 adept it to current best practices of development. Since complete
 rewrites almost always fail, like we have seen with Zope 3 - I prefer
 changing Zope 2.

+1

 What I'm outlining here has of course almost nothing to do with the
 original idea and scope of Zope 2. Maybe at some point this should get
 a different name ;-)

I don't want to discuss names, but I think the next release from Zope 
trunk should be explicitly a new *major* release.


Cheers,

Yuppie
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread Leonardo Rochael Almeida
Hi Hanno,

From the point of view of the ERP5 codebase, this direction for Zope2
should be mostly ok, save for a few comments below:

On Sun, Jul 3, 2011 at 03:41, Hanno Schlichting ha...@hannosch.eu wrote:
 On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida
 leoroch...@gmail.com wrote:
 [...]

 I think moving to Zope 2.12 and 2.13 does have some value for Nexedi
 or other large existing codebases, as you get support for current
 versions of the ZODB, Zope Toolkit packages and support for Python 2.7
 with Zope 2.13. Since Python 2.7 is a long-term maintenance release
 for Python itself, this should provide a stable and good basis for the
 next years - the statements from the Python community aren't
 completely clear - but I'd expect to see ongoing maintenance until
 2013 or maybe even 2015.

Yes, these were the reasons we ported to Zope 2.12 to begin with.

 Going forward I can see two paths for Zope 2. Either we don't touch it
 at all anymore and let it bitrot or we try to move it forward and
 adept it to current best practices of development. Since complete
 rewrites almost always fail, like we have seen with Zope 3 - I prefer
 changing Zope 2.

Agreed.

 If you are interested in stability I think sticking with an older
 version of Zope 2 is a completely sane and good approach. What me and
 others from the Plone community are trying to do with the Zope 2
 codebase is to actually move it forward. We can either do that as part
 of the official Zope 2 release series or fork the codebase. Since so
 far there isn't really anyone else interested in working on the Zope 2
 codebase, we keep changing Zope 2 without forking it.

With the direction the Zope2 codebase has taken so far, I don't see
any reason to fork it even if all current players keep depending on
it.

 But can you explain to us a little of how you expect Zope2 to behave
 with the changes you're doing?

 There's a number of things I want to do. Not sure when I'll or others
 will have the time, but these are things I expect to happen in the
 next months or releases:

 - Continue to remove functionality tailored for TTW development, like
 SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
 - Document and use the WSGI publisher and remove obsoleted
 functionality like the virtual host monster, error_log,
 ZServer/medusa, zopectl/zdaemon

In ERP5, we've made TTW development sane and safe, and integrated with
VCSs (both SVN and Git), so the above paragraph sounds  a little bit
scary, though in reality it doesn't have to be.

SiteRoot, AccessRules, HelpSys, of course, are really unused, so I
don't fear their disappearance.

As for the rest, most of the things that have been removed from core
were done in such a way that they can still be used with Zope2, so
ERP5 can happily keep using them. If things can keep evolving with
this care we should be ok.

As others have pointed out, the core url rewriting functionality of
VHM is useful even in a WSGI context, and I'd argue that it should
actually be made part of the root Application, so that we don't need a
persistent object just for this.

On the other hand, if we could get the ZTK version of this working
(the one that used /++vh-host and /++vh-root url segments) I think it
should be ok, and we could get rid of VHM completely.

 - Make the browser id manager, session data manager, temporary storage
 optional and remove it and request.SESSION from the core, instead we
 can use something based on Products.BeakerSessionDataManager /
 collective.beaker if someone has a need for sessions
 - Start using and storing parent pointers and remove
 Acquisition.Implicit from the most common base classes (a branch for
 this already exists with almost all core tests passing)

ERP5 will probably get rid of all its uses of acquisition too at some
point. We've recently taken a large step in this direction, but again,
it can still be used as an add-on, so this is not a problem.

 - Merge five.pt (Chameleon) into the core and use it instead of the
 zope.tal/zope.tales implementation (which means no more
 RestrictedPython for templates).

A few months ago, I and Malthe did some work to make sure that TTW
ZPTs worked with five.pt. Malthe even surprised me with something that
I thought couldn't possibly work and managed to get the
RestrictedPython evaluator to translate python expressions in TTW
ZPTs. So, getting rid of RestrictedPython is not strictly necessary
for using five.pt in Zope2 core.

Then again, we might decide to get rid of it for other reasons...

Anyway, as long as there are still TTW addable ZPTs, PythonScripts and
ZSQLMethods, ERP5 can still work.

 - Once most of the ZMI is gone, it should be feasible to drop DTML or
 rewrite what little is left as page templates

If DTML is still available as an optional product/package, this should
not be a problem for us, but we'll likely depend on ZSQLMethods
(hence, on DTML) for a long time, since our ZSQLCatalog functionality
is built heavily around it.

 

Re: [Zope-dev] direction

2011-07-04 Thread Martin Aspeli
Something of a meta-comment on this thread:

It sounds like people are broadly in agreement on the direction, but not
communicating enough about what's actually going on.

I think it would be useful to keep some kind of roadmap wiki on zope.org, or
at least post to the list periodically saying, this is what we're about to
start doing.

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread Laurence Rowe
On 4 July 2011 13:04, Leonardo Rochael Almeida leoroch...@gmail.com wrote:
 On the other hand, if we could get the ZTK version of this working
 (the one that used /++vh-host and /++vh-root url segments) I think it
 should be ok, and we could get rid of VHM completely.

The BlueBream URL syntax is no better than the existing VHM syntax, it
makes for insanely complex proxy configs. The repoze.vhm approach of
using headers is much, much simpler. However we choose to integrate it
(whether as middleware or some other way,) lets at least use the
simple approach of setting headers or hard coding in paste/whatever
config.

Laurence
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread Wichert Akkerman
On 2011-7-4 11:59, Marius Gedminas wrote:
 On Sun, Jul 03, 2011 at 06:10:48PM +0200, Wichert Akkerman wrote:
 On 2011-7-3 17:48, Martin Aspeli wrote:
 FWIW, we have a high-performance, high-load application in production on
 Plone 4 with collective.beaker relying heavily on sessions, and I'm not
 aware of any problems with it. We use the memcached backend across two
 physical servers and a large number of Zope clients.

 In my experience it depends highly on the memcache client library you
 use with beaker. With some the results are disastrous, with other it is
 stable. Where possible I have switched to cookie-based sessions to
 prevent stability problems.

 Aren't all sessions cookie-based?

 Did you mean you switched to secure cookies instead of server-side state?

I meant the cookie-backend, which indeed securely stores all data in a 
cookie instead of keeping any state serverside.

Wichert.


-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-03 Thread Hanno Schlichting
On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough chr...@plope.com wrote:
 Zope still needs to the virtual host monster (or something like it) even
 with the WSGI publisher; there's nothing equivalent in the WSGI world
 (unless you could repoze.vhm, which is essentially just the virtual host
 monster, and probably doesn't need to live in middleware; no one uses it
 except people who use repoze.zope2).

I'm expecting us to use repoze.vhm. But I've left the VHM in the code,
so it's easy to install one if you still need it. For some time I
expect Plone to install a VHM as part of its installation process.

 I don't have any skin in this game, but FTR, Mike Bayer isn't feeling
 all that confident about Beaker's sessioning component (or so he has
 told me).  Beaker was originally made as a caching component, and had
 sessioning jammed into it quite late; nobody is really maintaining the
 sessioning component of it now.

Well, if I can choose between modern unmaintained code from Mike Bayer
and stone-age unmaintained code from Zope, it's still an easy choice
;-)

And looking at the basics of what Beaker does here, it's still much
more useful and of better quality than what we have in Zope 2.

If there's any other non-framework-specific session machinery out
there, we could use that as well. But I think most other stuff is tied
into Django.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-03 Thread Martin Aspeli
On 3 July 2011 16:44, Hanno Schlichting ha...@hannosch.eu wrote:

 On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough chr...@plope.com wrote:
  Zope still needs to the virtual host monster (or something like it) even
  with the WSGI publisher; there's nothing equivalent in the WSGI world
  (unless you could repoze.vhm, which is essentially just the virtual host
  monster, and probably doesn't need to live in middleware; no one uses it
  except people who use repoze.zope2).

 I'm expecting us to use repoze.vhm. But I've left the VHM in the code,
 so it's easy to install one if you still need it. For some time I
 expect Plone to install a VHM as part of its installation process.

  I don't have any skin in this game, but FTR, Mike Bayer isn't feeling
  all that confident about Beaker's sessioning component (or so he has
  told me).  Beaker was originally made as a caching component, and had
  sessioning jammed into it quite late; nobody is really maintaining the
  sessioning component of it now.

 Well, if I can choose between modern unmaintained code from Mike Bayer
 and stone-age unmaintained code from Zope, it's still an easy choice
 ;-)

 And looking at the basics of what Beaker does here, it's still much
 more useful and of better quality than what we have in Zope 2.

 If there's any other non-framework-specific session machinery out
 there, we could use that as well. But I think most other stuff is tied
 into Django.


FWIW, we have a high-performance, high-load application in production on
Plone 4 with collective.beaker relying heavily on sessions, and I'm not
aware of any problems with it. We use the memcached backend across two
physical servers and a large number of Zope clients.

Martin
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-03 Thread Wichert Akkerman
On 2011-7-3 17:48, Martin Aspeli wrote:
 FWIW, we have a high-performance, high-load application in production on
 Plone 4 with collective.beaker relying heavily on sessions, and I'm not
 aware of any problems with it. We use the memcached backend across two
 physical servers and a large number of Zope clients.

In my experience it depends highly on the memcache client library you 
use with beaker. With some the results are disastrous, with other it is 
stable. Where possible I have switched to cookie-based sessions to 
prevent stability problems.

Wichert.


-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-03 Thread Chris McDonough
On Sun, 2011-07-03 at 17:44 +0200, Hanno Schlichting wrote:
  I don't have any skin in this game, but FTR, Mike Bayer isn't feeling
  all that confident about Beaker's sessioning component (or so he has
  told me).  Beaker was originally made as a caching component, and had
  sessioning jammed into it quite late; nobody is really maintaining the
  sessioning component of it now.
 
 Well, if I can choose between modern unmaintained code from Mike Bayer
 and stone-age unmaintained code from Zope, it's still an easy choice
 ;-)

You might want to talk to Wiggy about that.  He has a lot of experience
with Beaker.

 And looking at the basics of what Beaker does here, it's still much
 more useful and of better quality than what we have in Zope 2.
 
 If there's any other non-framework-specific session machinery out
 there, we could use that as well. But I think most other stuff is tied
 into Django.

Our attempt at penance (still framework specific) is here:

http://agendaless.com/Members/tseaver/software/faster/faster-0.5.1/README.txt

I don't know of any other sessioning libraries.

- C


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-02 Thread Hanno Schlichting
On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 I noticed you've been very busy doing clean-up on the Zope2 code base
 in the last few hours. As someone who has recently spent a lot of time
 porting forward a large and mission-critical code base, ERP5, from
 Zope 2.8 to Zope 2.12, I'm a little confused about the direction that
 you're moving, and how much effort that could mean for future porting
 efforts for Nexedi.

I think moving to Zope 2.12 and 2.13 does have some value for Nexedi
or other large existing codebases, as you get support for current
versions of the ZODB, Zope Toolkit packages and support for Python 2.7
with Zope 2.13. Since Python 2.7 is a long-term maintenance release
for Python itself, this should provide a stable and good basis for the
next years - the statements from the Python community aren't
completely clear - but I'd expect to see ongoing maintenance until
2013 or maybe even 2015.

Going forward I can see two paths for Zope 2. Either we don't touch it
at all anymore and let it bitrot or we try to move it forward and
adept it to current best practices of development. Since complete
rewrites almost always fail, like we have seen with Zope 3 - I prefer
changing Zope 2.

If you are interested in stability I think sticking with an older
version of Zope 2 is a completely sane and good approach. What me and
others from the Plone community are trying to do with the Zope 2
codebase is to actually move it forward. We can either do that as part
of the official Zope 2 release series or fork the codebase. Since so
far there isn't really anyone else interested in working on the Zope 2
codebase, we keep changing Zope 2 without forking it.

 But can you explain to us a little of how you expect Zope2 to behave
 with the changes you're doing?

There's a number of things I want to do. Not sure when I'll or others
will have the time, but these are things I expect to happen in the
next months or releases:

- Continue to remove functionality tailored for TTW development, like
SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
- Document and use the WSGI publisher and remove obsoleted
functionality like the virtual host monster, error_log,
ZServer/medusa, zopectl/zdaemon
- Make the browser id manager, session data manager, temporary storage
optional and remove it and request.SESSION from the core, instead we
can use something based on Products.BeakerSessionDataManager /
collective.beaker if someone has a need for sessions
- Start using and storing parent pointers and remove
Acquisition.Implicit from the most common base classes (a branch for
this already exists with almost all core tests passing)
- Merge five.pt (Chameleon) into the core and use it instead of the
zope.tal/zope.tales implementation (which means no more
RestrictedPython for templates)
- Once most of the ZMI is gone, it should be feasible to drop DTML or
rewrite what little is left as page templates

I think what's going to stay is AccessControl, OFS (a bit lighter),
ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of
Zope Toolkit libraries like components, events, browser pages and so
on.

That's the kind of scope that should be possible to port to Python 3
and actually modernize enough to be understandable. At that point we
should even be able to catch up with years of missed security updates
- almost nothing in current Zope 2 protects against XSS, CSRF or any
of the other common security risks we have on the web today.

What I'm outlining here has of course almost nothing to do with the
original idea and scope of Zope 2. Maybe at some point this should get
a different name ;-)

I hope this makes the direction of where I am headed clearer or more
generally what Plone expects from its underlying framework.

Hanno
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-02 Thread Chris McDonough
On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote:

 - Continue to remove functionality tailored for TTW development, like
 SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
 - Document and use the WSGI publisher and remove obsoleted
 functionality like the virtual host monster, error_log,
 ZServer/medusa, zopectl/zdaemon

Zope still needs to the virtual host monster (or something like it) even
with the WSGI publisher; there's nothing equivalent in the WSGI world
(unless you could repoze.vhm, which is essentially just the virtual host
monster, and probably doesn't need to live in middleware; no one uses it
except people who use repoze.zope2).

 - Make the browser id manager, session data manager, temporary storage
 optional and remove it and request.SESSION from the core, instead we
 can use something based on Products.BeakerSessionDataManager /
 collective.beaker if someone has a need for sessions

I don't have any skin in this game, but FTR, Mike Bayer isn't feeling
all that confident about Beaker's sessioning component (or so he has
told me).  Beaker was originally made as a caching component, and had
sessioning jammed into it quite late; nobody is really maintaining the
sessioning component of it now.

- C


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )