Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Hi Martin. The concern is building high volume applications using z3, 
the memory footprint for virtual hosting, and the unnecessary code that 
adds to burden of managing security. **I only want the code I use**.

I agree that the current situation does not stop folks from getting 
things done but overall z3 as a development platform is looking not so 
attractive for these reasons. It is analogous to packing two suitcases 
of clothes for a trip and finding you just needed a change of underwear 
and a shirt. Frankly is just getting difficult to accept the status quo 
anymore so hoping folks can get behind this sort of effort.

I am trying to avoid the need for selective forking that Chris has found 
necessary to make progress with bfg. I want to continue using zope since 
these things are a big factor for the factors I stated.


Martin Aspeli wrote:
 Hi David,
 
 David Pratt wrote:
 
 I am feeling increasing pressure and frustration to re-examine what I am 
 doing. Zope has a wonderful code base but it is spread through many 
 packages in the form of dependencies. As a result, a small app in a 
 working z3 setup can start off at almost 50MB while the similar app on a 
 competitive framework may be as little as 15 - 20 MB.
 
 Are you worried about disk space? Memory footprint?
 
 I guess the simple solution is well it you don't like it, use the 
 another framework. Its not quite that simple since I am extremely fond 
 of the CA architecture and have a strong desire to continue with it in 
 some form or another into the future. I think what I am sensing more 
 than anything is a need for zope to adapt a changing reality.
 
 zope.component, at least, is one of the packages that *does* work 
 without the world. :)
 
 bfg is a relatively new framework that builds on wsgi and zope 
 technologies but is an example of what can be achieved if you consume 
 only what you need. 
 
 True. I'd say that repoze.bfg is very much part of the Zope world, 
 though. It's an example of what Zope (and it's splitting of things into 
 many packages) has made possible.
 
 It is attractive in a number of respects for zope 
 developers since it offers simplicity and development speed with a 
 lightweight footprint.
 
 Yep. It's nice. :)
 
 I believe much of what is being accomplished in 
 bfg could be accomplished in zope if it were tighter and we could focus 
 on a leaner core of packages void of the large number of dependencies. 
 
 Reducing unneeded dependencies would indeed be a good architectural 
 goal. However, I'm not sure that having a few extra packages today is 
 stopping people from getting things done.
 
 I think there are couple of options. One option would be to set about on 
 a course of change to do something about this with the existing 
 codebase. Another option is to create a core of leaner packages that 
 could result in a much smaller, tighter core that can be competitive 
 with the changing python landscape.
 
 I'm not sure that another armageddon of Zope - starting it all again 
 in search of something better - will serve anybody or go particularly 
 far. I don't think that's what bfg is doing; I think it's using the 
 power of Zope 3 and the CA to selectively swap out the bits it doesn't 
 like for new bits. I see that as Zope delivering, not Zope failing.
 
 bfg is currently taking the option 
 of selectively forking some of the packages such as zope.catalog as 
 repoze.catalog for example. Personally, I would like to see these 
 changes occur in some way within zope.
 
 +1, but only where it actually makes sense. I'm not sure about 
 repoze.catalog... but quite often, you may get a repoze.* that's just a 
 wrapper around a zope.* package to make it easier to integrate with a 
 particular framework (bfg). That's the way re-use normally happens, I think.
 
 Martin
 

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


Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Hi Roger. Great. I am willing to help with this. I understand the 
politics of change and feel there is most likely less impetus for change 
for those consuming packages as opposed to folks like yourself or I that 
use zope 3 as our framework. This is something that has to happen. The 
situation has gone on too long and the answer has been to exclude 
configuration. This is only a partial solution at best.

Roger Ineichen wrote:
 Hi David
  
 Betreff: [Zope-dev] Dependencies and future of zope 3

 Hi there. I have been developing with zope3 for about 4 years 
 and would like to see zope continue in a healthy way into the 
 future. The last couple of years particularly have brought 
 significant change in how we deploy zope particularly with 
 wsgi with or without the zodb. In addition, there is a 
 increasing plethora of lightweight frameworks emerging to 
 compete with mind share and feel zope is loosing ground in 
 this respect.

 I am feeling increasing pressure and frustration to 
 re-examine what I am doing. Zope has a wonderful code base 
 but it is spread through many packages in the form of 
 dependencies. As a result, a small app in a working z3 setup 
 can start off at almost 50MB while the similar app on a 
 competitive framework may be as little as 15 - 20 MB. To some 
 extent, there is complexity in the politics of change needed 
 since zope is largely consumed as packages by z2 (Plone). So 
 the impetus for change may be less than favorable for those 
 consuming packages in Plone as opposed to a developer 
 interested in creating larger scale apps purely from zope 3 
 and other python packages.

 The key concern is dependencies. There have been efforts I 
 realize to settle some of this over the past but in reality 
 the volume of zope packages that comed together for a base 
 build is 'pulling in the world' 
 as i have heard it referred to many times. The testing setup 
 is another major factor in this and the changes controversial 
 over the eliminating the testing framework as a dependency of 
 zope eggs.

 I guess the simple solution is well it you don't like it, use 
 the another framework. Its not quite that simple since I am 
 extremely fond of the CA architecture and have a strong 
 desire to continue with it in some form or another into the 
 future. I think what I am sensing more than anything is a 
 need for zope to adapt a changing reality.

 bfg is a relatively new framework that builds on wsgi and 
 zope technologies but is an example of what can be achieved 
 if you consume only what you need. It is attractive in a 
 number of respects for zope developers since it offers 
 simplicity and development speed with a lightweight 
 footprint. I believe much of what is being accomplished in 
 bfg could be accomplished in zope if it were tighter and we 
 could focus on a leaner core of packages void of the large 
 number of dependencies. 
 The grokcore packages can help with the simplicity 
 development but do little for the dependency issues.

 I think there are couple of options. One option would be to 
 set about on a course of change to do something about this 
 with the existing codebase. Another option is to create a 
 core of leaner packages that could result in a much smaller, 
 tighter core that can be competitive with the changing python 
 landscape. bfg is currently taking the option of selectively 
 forking some of the packages such as zope.catalog as 
 repoze.catalog for example. Personally, I would like to see 
 these changes occur in some way within zope. In any case I am 
 interested in hearing from folks about what can or ought to 
 be done or whether there is interest in this direction. Many thanks.
 
 +1
 
 I fully agree. I put the dependency cleanup on my task list
 and started the last couple days with reviewing the 
 zope core packages.
 
 I think everybody whould be happy if we provide less
 dependencies. But if it comes to move things arround we
 really have a lot of work with convince everybody.
 
 It whould really help if we could build a team of developers
 which volunteer to review such cleanup work. That makes it
 easier to make decisions and avoids that people get stocked
 with their cleanup work.
 
 Is someone willing to help doing that task? 
 
 Regards
 Roger Ineichen
 
 Regards
 David
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  ** (Related lists -  
 http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )

 
 

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


Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Roger, you make excellent sense here. The other issue of course is the 
testing setup. So there is potential to operate here on a few levels to 
achieve something that makes much better sense for moving forward.

Roger Ineichen wrote:

 I think the cleanup isn't really needed for zope packages itself.
 It's more a question how other can reuse small parts of our
 component architecture without to load everything.
 
 My personal meaning is, we already have a component architecture
 but we need to split it in a different way into reusable components.
 Such a split could probably not be done earlier because we didn't
 see all the usecases. But now since we have grok, repoze and z3c 
 we have many more options to reuse other components and this makes
 it much clearer what we have to provide as reusable and what not. 
 
 Regards
 Roger Ineichen
 
 -aj
 
 

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


Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Hey Martijn. These are good ideas. I also find myself importing a 
package for some interfaces which sort of sucks too and which there were 
perhaps a better solution for.

Martijn Faassen wrote:
 Hi there,
 Roger Ineichen wrote:
 [snip]
 Is someone willing to help doing that task? 
 
 I'm very interested in this topic as well, especially from the 
 perspective of Grok of course.
 
 There are many strategies to go ahead in doing this. I'll list just one 
 observation I've had here.
 
 One observation is that the pattern of '.browser' subpackages tends to 
 expand the dependency structure significantly. Often you want to use 
 non-browser functionality and don't care about the UI that ships with 
 .browser. At the same time .browser tends to add dependencies to the 
 overall package.
 
 Other times (such as for zope.app.form.browser) the main reusable 
 functionality of a package is actually almost completely in the .browser 
 sub package. It might be nicer to flatten the namespace then and move 
 things from .browser into the main package.
 
 It might therefore make sense to review packages one by one, and see 
 whether zope.foo.browser can be factored out into a zope.fooui package 
 or something like that. Of course the question remains how we can get 
 from A to B without a major breakage in backwards compatibility then.
 
 Regards,
 
 Martijn
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 

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


Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces

2008-09-03 Thread David Pratt
You may wish to look at z3c.dobbin, though the issue I have found in my 
own experimentation, is with association tables for many to many 
relationships which throws in a wrench into this otherwise elegant 
solution. There may be something to around this in future.

Hermann Himmelbauer wrote:
 Hi,
 In my current SQLAlchemy / Zope-based design, I need the following:
 
 - SQLAlchemy table definitions
 - classes + mappers
 - Zope interfaces
 
 The problem with this design is that much data has to be defined twice, e.g. 
 the datatype varchar(50) should be represented by an interface with 
 TextLine(max_length=50). Moreover, any changes such as adding columns etc. 
 also have to be done in the interface and the table definition.
 
 To overcome this, I just had the idea to use the interface/schema definitions 
 for the table definition itself. Probably I'm not the first who had this 
 idea, but I'm not aware of such an extension to interfaces.
 
 Any thoughts on this?
 
 Best Regards,
 Hermann
 

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


Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Hi Martijn. As a side note I have found immense value in the effort to 
split out the grok packages as it is has been very useful in my own 
development. I have been looking for you on irc to discuss this further 
to create a grokcore.traverser package and another package to abstract 
grok.Model (that depends more upon grokcore.component), grok.Container 
and grok.Application.

This abstraction paves the way for general usage of megrok.rdb, 
megrok.rdb, and megrok.trails without the grok dependency and can bring 
the general usage of the model concept into regular z3. You would not 
believe how much this can reduce the volume of your package with these 
things.

My preference is not to develop in grok, but at the same time these 
packages are excellent as I can selectively use them to reduce 
configuration and volume in my packages and not loose anything in the 
process so it is very much appreciated what you have done here.


Martijn Faassen wrote:
 Benji York wrote:
 On Wed, Sep 3, 2008 at 8:40 AM, David Pratt [EMAIL PROTECTED] wrote:

 I am trying to avoid the need for selective forking that Chris has found
 necessary to make progress with bfg. I want to continue using zope [...]
 +1  Experimental forks to help determine what refactoring need to be
 done in the mother package are fine, but I hope that the findings of
 Plone, Grok, and repoze/bfg can all be folded back in.
 
 Agreed with this. We want Zope 3 packages to move forward, so I'm very 
 glad that David took up this discussion. It's important we develop a bit 
 of vision here, some guidelines, and a plan on how to get there step by 
 step.
 
 Note that Grok hasn't been forking Zope 3 packages. We've built a few 
 packages on top of Zope 3 that are now reusable with straight Zope 3 
 too, to wit, grokcore.component, grokcore.view and grokcore.security and 
 soon grokcore.formlib. Grok has its own approaches of course, but one 
 thing we spent quite a bit of time on is to be good Zope 3 citizens.
 
 Grok 0.14 will be built on top of these grokcore.*, and we took pains to 
 make these compatible with straight Zope 3 projects as well. This means 
 that if you want Grok-style configuration of adapters, views and 
 utilities in your Zope 3 project or library you can use these projects. 
 I have a few z3c packages sitting around that I hope to convert to use 
 these once Grok 0.14 is released. These packages are already finding 
 some uptake in Zope 2 projects as well. It's been interesting to see how 
 the requirements to reuse bits of Grok in Zope 3 and Zope 2 have been 
 pulling togeter to help factor these packages out.
 
 I think the only bit that you can really consider a 'fork' is 
 grokproject itself, which is like an improved zopeproject. If someone 
 wants to take it up, we could start factoring out a common core there as 
 well.
 
 Regards,
 
 Martijn
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 

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


Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Hi Jim. Here is an idea I have that can help bring perspective and 
change. I propose that if we had the efforts of a few developers to work 
on a single reference application, and the eyes of others willing to 
inspect the package we could all benefit.

The idea would be to make the reference application as lightweight as 
possible and work backwards so that we can measure change. This would be 
a simple wsgi application. I propose we use cluemapper since it is 
simple, small and would take little time. We can create the reference 
app with different backends so we can see effect of zodb also.

The idea would be to use the reference to expose the issues, propose and 
make changes, and measure the impact of changes we are making. We also 
see how competitive we are compared to equivalent application on another 
framework in terms of no of app files, RAM consumption, no of packages, 
or other measures that would be important to developers.

We can target the dependencies from the perspective of the impact it is 
having on something real as opposed to perceived.  A second benefit is 
that we can use the application to educate folks on simple and 
lightweight zope development with wsgi.


Jim Fulton wrote:
 Some high-level remarks:
 
 I agree with your sentiments.  I too would like to see Zope 3 technology 
 become more usable for lightweight applications.  I'd like to see the 
 existing code base evolve in that direction.
 
 Unfortunately, Zope 3 evolved as a monolithic development tree.  
 Tendrils formed between packages that should have been independent.  
 There was no incentive to keep things cleanly separated.
 
 I'm certain that this is fixable, but it will take a lot of work.  I 
 think this is happening slowly.  Many of us have day jobs and it's 
 hard to make this a priority.
 
 Jim
 
 
 On Sep 2, 2008, at 8:54 PM, David Pratt wrote:
 
 Hi there. I have been developing with zope3 for about 4 years and would
 like to see zope continue in a healthy way into the future. The last
 couple of years particularly have brought significant change in how we
 deploy zope particularly with wsgi with or without the zodb. In
 addition, there is a increasing plethora of lightweight frameworks
 emerging to compete with mind share and feel zope is loosing ground in
 this respect.

 I am feeling increasing pressure and frustration to re-examine what I am
 doing. Zope has a wonderful code base but it is spread through many
 packages in the form of dependencies. As a result, a small app in a
 working z3 setup can start off at almost 50MB while the similar app on a
 competitive framework may be as little as 15 - 20 MB. To some extent,
 there is complexity in the politics of change needed since zope is
 largely consumed as packages by z2 (Plone). So the impetus for change
 may be less than favorable for those consuming packages in Plone as
 opposed to a developer interested in creating larger scale apps purely
 from zope 3 and other python packages.

 The key concern is dependencies. There have been efforts I realize to
 settle some of this over the past but in reality the volume of zope
 packages that comed together for a base build is 'pulling in the world'
 as i have heard it referred to many times. The testing setup is another
 major factor in this and the changes controversial over the eliminating
 the testing framework as a dependency of zope eggs.

 I guess the simple solution is well it you don't like it, use the
 another framework. Its not quite that simple since I am extremely fond
 of the CA architecture and have a strong desire to continue with it in
 some form or another into the future. I think what I am sensing more
 than anything is a need for zope to adapt a changing reality.

 bfg is a relatively new framework that builds on wsgi and zope
 technologies but is an example of what can be achieved if you consume
 only what you need. It is attractive in a number of respects for zope
 developers since it offers simplicity and development speed with a
 lightweight footprint. I believe much of what is being accomplished in
 bfg could be accomplished in zope if it were tighter and we could focus
 on a leaner core of packages void of the large number of dependencies.
 The grokcore packages can help with the simplicity development but do
 little for the dependency issues.

 I think there are couple of options. One option would be to set about on
 a course of change to do something about this with the existing
 codebase. Another option is to create a core of leaner packages that
 could result in a much smaller, tighter core that can be competitive
 with the changing python landscape. bfg is currently taking the option
 of selectively forking some of the packages such as zope.catalog as
 repoze.catalog for example. Personally, I would like to see these
 changes occur in some way within zope. In any case I am interested in
 hearing from folks about what can or ought to be done or whether there
 is interest

Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Hey Roger. Sounds reasonable to me. Can we also discuss the potential
of only including testing setup for dev eggs and removing testing as
part of a release when the eggs are packaged to pypi or other
repository for consumption.

Besides loosing the dependency, this makes for happier folks external
to zope that consume our eggs.

While I personally do not like the contributor agreement, I am willing
to sign to help out to work with you and others to get this settled. I
am busy just like anyone else, but this stuff with the dependencies
has to end now. Weve been with eggs for more than a couple years,
progress has been made but it has been slow. Seriously, let's see what
we can do to.

The browser packages are a good place to start. Testing another. Third
would be seriously examining dependencies of core again once this is
done. Fourth might be tackling some of the zope.xxx zope.app.xxx
relationships. Some of the stale packages in the main repository and
placing them at another location if they are unmaintained might also
be in order.

If we want to folks to use zope we need to be friendly to wsgi with or
without a zodb and show both sides of the coin - that CA + choice of
backend + zope security + choice of traversal method (with publisher)
== interesting, productive, mature, dynamic and efficient.

On Wed, Sep 3, 2008 at 3:06 PM, Roger Ineichen [EMAIL PROTECTED] wrote:
 Hi

 Betreff: Re: [Zope-dev] Dependencies and future of zope 3

 On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter
 [EMAIL PROTECTED] wrote:

  For several packages we took the following approach. Most packages
  that have browser packages are in zope.app; for example,
  zope.app.folder (we did not convert this package yet). We
 then took the API and moved it to zope.folder.

 Maybe we should create a new namespace package for browser code.

 How about zope.browser?

 Most packages which are interesting for reuse
 provide more or less only ZMI related views.

 What about zope.zmi if they provide views for
 the ZMI. This views are allmost unuseable
 outside the ZMI (know as Rotterdam skin)

 Regards
 Roger Ineichen

 --
 Benji York
 Senior Software Engineer
 Zope Corporation
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  ** (Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )


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

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


Re: [Zope-dev] Dependencies and future of zope 3

2008-09-03 Thread David Pratt
Roger, what you say makes good sense. I will get agreement signed and
sent and off to Jim. I am much more optimistic than I have been for a
long time. This stuff has really been bothering me since I am
concerned about efficient wsgi virtual host deployments and zope is
unnecessarily heavy.

Personally I would like to see a core zope install with a footprint of
no more that 20MB with just essential packages. I am a believer in
zope and I am encouraged by the support for change. I also realize
some of this will be disruptive but it is necessary.  A wiki page will
be helpful to communicate and get the best ideas for moving ahead.
There are a number of good folks here that understand the
circumstances so we have an excellent opportunity to act on this.

On Wed, Sep 3, 2008 at 9:09 PM, Roger Ineichen [EMAIL PROTECTED] wrote:
 Hi David

 Betreff: Re: [Zope-dev] Dependencies and future of zope 3

 Hey Roger. Sounds reasonable to me. Can we also discuss the
 potential of only including testing setup for dev eggs and
 removing testing as part of a release when the eggs are
 packaged to pypi or other repository for consumption.

 I guess we do not have tets eggs. What do you mean with
 test eggs.

 I think extras_require test is a pattern which let's you
 use the extras or not if you use an egg. By default
 an egg has only dependencies the defined packages
 in install_requires. Or are I'm wrong?

 Besides loosing the dependency, this makes for happier folks
 external to zope that consume our eggs.

 While I personally do not like the contributor agreement, I
 am willing to sign to help out to work with you and others to
 get this settled. I am busy just like anyone else, but this
 stuff with the dependencies has to end now. Weve been with
 eggs for more than a couple years, progress has been made but
 it has been slow. Seriously, let's see what we can do to.

 Cool any help is welcome.

 The browser packages are a good place to start. Testing
 another. Third would be seriously examining dependencies of
 core again once this is done. Fourth might be tackling some
 of the zope.xxx zope.app.xxx relationships. Some of the stale
 packages in the main repository and placing them at another
 location if they are unmaintained might also be in order.

 I think we should start with identify the hard core dependencies
 and list them in a proposal or another document in the zope wiki.
 Anybody can list their ideas of what should be done and list
 ideas how we can solve the problems. We also can use that
 paper for vote about the different refactorings.

 Such a proposal/paper could also be usefull for others which
 don't read each mail.

 We have different kind of refactorings which all solve some
 problems. I think we should not start with the browser views.
 There are some core dependencies we need to cleanup first.

 Right now I'm working forward with small refactorings
 which solve some dependencies to zope.app.form (ITerms) and
 zope.app.authentication (IPaswordManager).

 After that, my goal is to work on the testing framework,
 offering a clean testing (skin) layer, which should make it
 possible to write functional tests without to use the basic,
 default or rotterdam skin and the zope.app.authentication
 package.

 I guess that's what the repoze people need to have too.

 Your help is defently very welcome. Go ahead with the
 contributor agreement sing up and let Jim know that
 I volunteer for you.


 If we want to folks to use zope we need to be friendly to
 wsgi with or without a zodb and show both sides of the coin -
 that CA + choice of backend + zope security + choice of
 traversal method (with publisher) == interesting, productive,
 mature, dynamic and efficient.

 Sounds interesting but let's put that on the todo later list.

 Regards
 Roger Ineichen
 _
 END OF MESSAGE

 On Wed, Sep 3, 2008 at 3:06 PM, Roger Ineichen
 [EMAIL PROTECTED] wrote:
  Hi
 
  Betreff: Re: [Zope-dev] Dependencies and future of zope 3
 
  On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter
  [EMAIL PROTECTED] wrote:
 
   For several packages we took the following approach.
 Most packages
   that have browser packages are in zope.app; for example,
   zope.app.folder (we did not convert this package yet). We
  then took the API and moved it to zope.folder.
 
  Maybe we should create a new namespace package for browser code.
 
  How about zope.browser?
 
  Most packages which are interesting for reuse provide more or less
  only ZMI related views.
 
  What about zope.zmi if they provide views for the ZMI. This
 views are
  allmost unuseable outside the ZMI (know as Rotterdam skin)
 
  Regards
  Roger Ineichen
 
  --
  Benji York
  Senior Software Engineer
  Zope Corporation
  ___
  Zope-Dev maillist  -  Zope-Dev@zope.org
  http://mail.zope.org/mailman/listinfo/zope-dev
  **  No cross posts or HTML encoding!  ** (Related lists -
  

[Zope-dev] Dependencies and future of zope 3

2008-09-02 Thread David Pratt
Hi there. I have been developing with zope3 for about 4 years and would 
like to see zope continue in a healthy way into the future. The last 
couple of years particularly have brought significant change in how we 
deploy zope particularly with wsgi with or without the zodb. In 
addition, there is a increasing plethora of lightweight frameworks 
emerging to compete with mind share and feel zope is loosing ground in 
this respect.

I am feeling increasing pressure and frustration to re-examine what I am 
doing. Zope has a wonderful code base but it is spread through many 
packages in the form of dependencies. As a result, a small app in a 
working z3 setup can start off at almost 50MB while the similar app on a 
competitive framework may be as little as 15 - 20 MB. To some extent, 
there is complexity in the politics of change needed since zope is 
largely consumed as packages by z2 (Plone). So the impetus for change 
may be less than favorable for those consuming packages in Plone as 
opposed to a developer interested in creating larger scale apps purely 
from zope 3 and other python packages.

The key concern is dependencies. There have been efforts I realize to 
settle some of this over the past but in reality the volume of zope 
packages that comed together for a base build is 'pulling in the world' 
as i have heard it referred to many times. The testing setup is another 
major factor in this and the changes controversial over the eliminating 
the testing framework as a dependency of zope eggs.

I guess the simple solution is well it you don't like it, use the 
another framework. Its not quite that simple since I am extremely fond 
of the CA architecture and have a strong desire to continue with it in 
some form or another into the future. I think what I am sensing more 
than anything is a need for zope to adapt a changing reality.

bfg is a relatively new framework that builds on wsgi and zope 
technologies but is an example of what can be achieved if you consume 
only what you need. It is attractive in a number of respects for zope 
developers since it offers simplicity and development speed with a 
lightweight footprint. I believe much of what is being accomplished in 
bfg could be accomplished in zope if it were tighter and we could focus 
on a leaner core of packages void of the large number of dependencies. 
The grokcore packages can help with the simplicity development but do 
little for the dependency issues.

I think there are couple of options. One option would be to set about on 
a course of change to do something about this with the existing 
codebase. Another option is to create a core of leaner packages that 
could result in a much smaller, tighter core that can be competitive 
with the changing python landscape. bfg is currently taking the option 
of selectively forking some of the packages such as zope.catalog as 
repoze.catalog for example. Personally, I would like to see these 
changes occur in some way within zope. In any case I am interested in 
hearing from folks about what can or ought to be done or whether there 
is interest in this direction. Many thanks.

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


Re: [Zope-dev] Re: zope.sqlalchemy dependencies does not respect setup.py dev egg

2008-08-04 Thread David Pratt
Hi Laurence. I reverted to 0.2 and I am good to go. I will upgrade to 
0.3 when dobbin can use beta0.5.3. Many thanks.


Regards,
David

Laurence Rowe wrote:

zope.sqlalchemy specifically requires a SessionExtension hook added in
0.4.7 and 0.5.0b3 to fix a bug that came to light in porting dobbin
over to use it:

New objects added to a session did not
cause a transaction join, so were not committed at the end of the
transaction unless the database was accessed. SQLAlchemy 0.4.7 or
0.5beta3 now required.

Other than that nothing really changed since 0.2, you should be able to 
just use that.


Laurence

David Pratt wrote:
Hi. I have been working with z3c.dobbin 0.4.1 which uses 
zope.sqlalchemy and z3c.saconfig. The last usable state was 4 days ago 
when changes were made to release of zope.sqlalchemy where 
dependencies were changed without changing the version.


Revision 88953 was made to zope.sqlalchemy but shows the same package 
version as 88952 (where SA dependencies were changed to no longer 
include beta0.5.2). beta0.5.2 was the requirement for z3c.dobbin and 
it will not work with beta0.5.3. Malthe is currently making changes to 
dobbin in the interim so it will eventually work again.


I thought by checking out revision 88952 and using it as a dev egg in 
my buildout, I could get back to work. Is this a bug in buildout since 
dev egg should take precedence regardless? I guess there were some 
problems with how this was handled. If trunk had been marked as 0.3dev 
it might have made the difference because both were 0.3 regardless of 
the change of state and dependencies. When I run the buildout the dev 
egg's requires.txt is below regardess of what is in setup.py.  Doesn't 
matter what I do my build fails. Any suggestions? Many thanks.


Regards,
David



requires.txt

setuptools
SQLAlchemy=0.4.7,!=0.5.0beta1,!=0.5.0beta2
transaction
zope.interface

[test]
zope.testing
docutils


setup.py

install_requires=[
  'setuptools',
  'SQLAlchemy==0.5.0beta2', # or =0.5b3
  'transaction',
  'zope.interface',
  ],
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )



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



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

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zope.sqlalchemy dependencies does not respect setup.py dev egg

2008-08-02 Thread David Pratt
Hi. I have been working with z3c.dobbin 0.4.1 which uses zope.sqlalchemy 
and z3c.saconfig. The last usable state was 4 days ago when changes were 
made to release of zope.sqlalchemy where dependencies were changed 
without changing the version.


Revision 88953 was made to zope.sqlalchemy but shows the same package 
version as 88952 (where SA dependencies were changed to no longer 
include beta0.5.2). beta0.5.2 was the requirement for z3c.dobbin and it 
will not work with beta0.5.3. Malthe is currently making changes to 
dobbin in the interim so it will eventually work again.


I thought by checking out revision 88952 and using it as a dev egg in my 
buildout, I could get back to work. Is this a bug in buildout since dev 
egg should take precedence regardless? I guess there were some problems 
with how this was handled. If trunk had been marked as 0.3dev it might 
have made the difference because both were 0.3 regardless of the change 
of state and dependencies. When I run the buildout the dev egg's 
requires.txt is below regardess of what is in setup.py.  Doesn't matter 
what I do my build fails. Any suggestions? Many thanks.


Regards,
David



requires.txt

setuptools
SQLAlchemy=0.4.7,!=0.5.0beta1,!=0.5.0beta2
transaction
zope.interface

[test]
zope.testing
docutils


setup.py

install_requires=[
  'setuptools',
  'SQLAlchemy==0.5.0beta2', # or =0.5b3
  'transaction',
  'zope.interface',
  ],
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope3 on Google AppEngine

2008-06-02 Thread David Pratt
Interesting post. I am still not sure to what level I'll look to Google 
for app infrastructure. Seems to me there are too many restrictions on 
what you'd really be able to deploy and then you're stuck with married 
to what they've got for better or worse. On the other hand, Stripping 
zope to the minimum has certainly been an eye opener and certainly 
beneficial to get to a bare bones idea of what you could run with (with 
or without Google) though. Many thanks for sharing your efforts on this.


Regards,
David

Kapil Thangavelu wrote:

perhaps too late to help with the sprints, but i got zope3 running on
app engine last week http://zope3.appspot.com and
http://zope3.appspot.com/tests, and blogged about to
http://blog.kapilt.com

most of zope.app isn't useable due to persistence or containment and
security proxies, but page templates and the publisher work. some
fairly minor but pervasive changes (removing some deprecations/bbb
code) were needed, and to have space (1000 file limit) to actually
develop an application requires stripping the eggs of text and tests.
i ended up using the publisher support in zope.publisher (3.5.1+)
instead of ore.wsgiapp or lovely.nozodb as it presents a much more
minimal dependency set.

i'd like to see if i can get some form machinery going underneat the
1000 file limit, and publish a starter tarball for folks interested.

i'm uncertain long term what's viable, as their were a number of
changes needed, and how best to maintain them. if their suitable for
upstream into the zope repository, or just done again for separate
releases as gae variant of z3.

cheers,

kapil

On 5/22/08, Jodok Batlogg [EMAIL PROTECTED] wrote:

Hi,

 Next week Lovely will be sprinting in New York/San Francisco to get the
Zope3 framework and the first applications running on Google AppEngine.
You're welcome to join us.
 Google AppEngine is a perfect match to the transition we at Lovely Systems
made during the last 12 month in stealth mode.
 We're using heavily WSGI and are replacing ZODB within most of our
applications.
 Tomorrow we're leaving to New York visiting our friend reco. dobee and I
will be working on getting the component architecture running on AppEngine.
 Later next week we'll fly to San Francisco to attend Google I/O and get
even more insight to the technology.
 We're open to release lovely.nozodb and the related components in near
future, as usual - just some polishing missing…
 Please drop me a note ([EMAIL PROTECTED], batlogg on skype/AIM) or
give me a call (+43 664 9636963) if you want to join us.

 jodok
 --
 Lovely Systems, Partner

 phone: +43 5572 908060, fax: +43 5572 908060-77
 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
 _

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

 http://mail.zope.org/mailman/listinfo/zope )



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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope and Storm (SQL)

2008-05-25 Thread David Pratt
Hi Jurgen. Thank you for keeping this thread going. It is helpful and 
good to experiment with this further for light applications. I have not 
given much attention to storage with orm since the early days of 
sqlalchemy. There have been many improvements since then to the various 
implementations. I believe Storm may be a bit more precise as to what it 
wants to be. That translates into a bit more speed from all accounts.


Jürgen kartnaller wrote:
On Sat, May 24, 2008 at 2:24 PM, David Pratt [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hi Jurgen. Thank you for this informative post. I am particularly
interested in how this fits into the refactoring of legacy code. I
appreciate your sharing your experiences. I also think everyone has
been paying much attention to the insight Lovely has been sharing on
scaling and efficient delivery of Zope over the past couple of years.

As a means of mapping one or more backends without changing the
logic or code with backend logic, schemas play an important role. I
can see the benefit of providing plain SQL statements since they are
clearly understood. The concern I have about not using schemas is
the loss of integration potential for the different backends using a
common pattern of mapping zope schema to xml, rdf, rdb, whatever ...
In your opinion, is this abstraction simply costing too much,
unnecessary, or a matter of application development and runtime speed.




Schemas provide the potential of mapping the object structure to other 
storage backends with different notions of persistence - so not a direct 
reference for xml to sql. As much as possible I do not want to change an 
app to use a different backend. With adaptation and classes that behave 
the same way in CA, it ought to be possible to only have to change 
import statements to different implementations of Contained, Location 
etc and generally change what you are subclassing from to persist data.


I'm not sure what you mean with schema/xml in context with SQL. You can 
still use your schema as you already do. I just wrote a CSV importer 
based on schema's together with formlib's Editform and AddForm.
The only diference you have is, that it is not possible to use 
FieldProperty in Storm classes.




For me, the crux of the rdb approach for legacy code is the
container, location and traversal. You have been very generous with
your examples. I am really hoping for a clearer idea of handling
Container, OrderedContainer, and Location which is prevalent in
legacy code. Overall, I can say that I quite the innovation here in
getting to a 'leaner' concept of Zope.


If you have your legacy code you have a clear definition what you need 
for your container. So it should be straight forward to implement 
IContainer and ILocated.


Yes, you are right. I'll experiment with what you have provided and see 
if I can get something basic working with the z3c.traverser package. 
BTW, I am assuming at this point that everything is registered in the 
global site manager for the app. I am not sure if it is possible to have 
a notion of local sites without the ZODB. This of course would required 
changes in legacy applications as well.



Without going too deep into this here is some code which should be usable:

class Container(Storm):
interface.implements(IContainer)
__storm_table__ = 'containers'
id = Int(primary=True)
content = ReferenceSet(id, 'Content.id')
def __iter__(self):
return self.content
def __getitem__(self, name):
item = self.content.find(Content.name == name).one()
if item is None:
raise KeyError
return item
self __setitem__(self, name, item):
item.name http://item.name = name # add namechooser things here
item.parent = self
def __len__(self):
return self.content.count()

class Content(Storm):
id = Int(primary=True)
name = Unicode()
parent = Reference(id, Container.id)


No worry about killing anyone :-) I appreciate this sketch. I believe 
Martijn and Brian were discussing a generic implementation of Container 
for the different alchemy flavors a few weeks back - an implementation 
that could live outside of these packages. It would be useful to have a 
decent generic implementation for rdb implementations. Many thanks.


Regards,
David


Don't kill me if something is wrong here, this is an untested quick hack 
to demonstrate what's possible. Also the IContainer interface is not 
fully implemented.




Regards,
David



Jürgen kartnaller wrote:

There seems to be some interest on the use of SQL databases with
Zope.

Lovelysystems is now using SQL databases as the primary storage
for their applications. We use Zope and Postgres with Storm as ORM.
The main reason for switching to SQL database were speed issues
with queries.

Here is a short summary

Re: [Zope-dev] Zope and Storm (SQL)

2008-05-24 Thread David Pratt
Hi Jurgen. Thank you for this informative post. I am particularly 
interested in how this fits into the refactoring of legacy code. I 
appreciate your sharing your experiences. I also think everyone has been 
paying much attention to the insight Lovely has been sharing on scaling 
and efficient delivery of Zope over the past couple of years.


As a means of mapping one or more backends without changing the logic or 
code with backend logic, schemas play an important role. I can see the 
benefit of providing plain SQL statements since they are clearly 
understood. The concern I have about not using schemas is the loss of 
integration potential for the different backends using a common pattern 
of mapping zope schema to xml, rdf, rdb, whatever ... In your opinion, 
is this abstraction simply costing too much, unnecessary, or a matter of 
application development and runtime speed.


For me, the crux of the rdb approach for legacy code is the container, 
location and traversal. You have been very generous with your examples. 
I am really hoping for a clearer idea of handling Container, 
OrderedContainer, and Location which is prevalent in legacy code. 
Overall, I can say that I quite the innovation here in getting to a 
'leaner' concept of Zope.


Regards,
David



Jürgen kartnaller wrote:

There seems to be some interest on the use of SQL databases with Zope.

Lovelysystems is now using SQL databases as the primary storage for 
their applications. We use Zope and Postgres with Storm as ORM.
The main reason for switching to SQL database were speed issues with 
queries.


Here is a short summary of my thougt's and experiences while using Storm 
and Zope for about 3 Month now.



RelStorage:
Relstorage doesn't solve the speed problems. Doing queries with SQL is 
much faster than doing it with ZODB. If you work with a lot and with 
large BTrees you need to load them all into the memory of each Zope 
client. This has to be done with Relstorage too.



Indexes:
You don't need to implement catalog indexes, this is all done on the 
database side. When implementing and using your content types, at first 
you don't need to think about indexes, later you optimize the database 
without touching your python code.


A speed example :
We had to find similar users based on items a user has collected. Doing 
this with ZODB took minutes to calculate for users with a lot of items. 
We had to implement a lot of code to do the calculation asynchronously 
to not block the users request.
Doing the same with SQL was possible with a single (of course complex) 
query within 300ms, no async things needed, just implement the query and 
optimize the indexes on the server, finished ! Relstorage will not help 
you here.



Content implementation:
While we are porting our existing ZODB based packages to SQL, we found 
that implementing them with Storm is as easy as using ZODB. We still can 
use the full power of Zope's component architecture. This is because 
Storm objects are extremely easy to implement. You can implement a storm 
object like a Persistent object, just derive from Storm instead of 
Persistent, add __storm_table__ and define the properties as Storm 
properties.


For me a big mistake when switching from ZODB to SQL is trying to use 
the container pattern at any cost.
A container is nothing but a  1:N relation and this is exactly what an 
SQL database provides : Relations


class Content(Storm):
id = Int(primary=True)
content = ReferenceSet(id, 'Contained.somethingId')
c = Content()

Now you can
 - add data : c.content.add(content)
 - iterate : for a in c.content:
 - search : c.content.find(...)
 - sort : c.content.find().sort_by(...)
 - do anything a Storm ResultSet is providing

But of course it is possible to put an adapter around the Content class 
which will provide IContainer.



Annotation:
Annotations are 1:1 relations, so it's as easy as the above.
We use annotations like simple adapters to other tables.

class ToBeAnnotated(Storm):
interface.implements(ICanHaveData)
id = Int(primary=True)

Note that the annotated storm table is implemented as an adapter :

class Data(Storm):
interface.implements(IData)
interface.adapts(ICanHaveData)
id = Int(primary=True)
__parent__ = Reference(id, ToBeAnnotated.id)
def _init__(self, context):
# a dummy to make the adapter happy
pass

We can now register Data as an adapter.
We use a special adapter factory like zope.annotation.factory to 
autocreate adapted content.


def contentAdapter(table, autocreate=True):
# an adapter on content for content contained in other tables. Just like
# the annotation adapter, an instance is created if autocreate is True.
adapts = component.adaptedBy(table)
if adapts is None:
raise TypeError(Missing 'zope.component.adapts' on table)
@component.adapter(list(adapts)[0])
@interface.implementer(list(component.implementedBy(table))[0])
def getAdapter(context):

Re: [Zope-dev] Zope3 on Google AppEngine

2008-05-23 Thread David Pratt
Hi Jodok. I had looked at storm a while back but the zope integration 
seemed to lack any relationship with zope schemas.  I guess it is 
possible to define a zope schema that is not persisted and create the 
tables from it. It did not seem to me a good way of using CA. How are 
you managing this part of things.


I Haven't worked with bigtable yet myself but assume the transactional 
semantics would be a challenge since I am not sure how quickly the data 
gets to the storage. This is interesting stuff in any case.


Regards,
David

Jodok Batlogg wrote:

On Thu, May 22, 2008 at 4:53 PM, David Pratt [EMAIL PROTECTED] wrote:

Hi Jodok. Sounds interesting. Curious what you are replacing ZODB with. Are
you using its interfaces to Relstorage / other ZODB backend, an ORM to map
direct to rdb, or other database. Many thanks.


right now we're using storm.
for the application we plan to port first it seems like bigtable fits perfect.
during the next week we won't focus on the storage layer, but more on
getting the C-based things running.
the other part - lovely.nozodb (zope3 without zodb, utility
registrations,...) is almost done and just needs some polishing.

jodok


Regards,
David

Jodok Batlogg wrote:

Hi,

Next week Lovely will be sprinting in New York/San Francisco to get the
Zope3 framework and the first applications running on Google AppEngine.
You're welcome to join us.
Google AppEngine is a perfect match to the transition we at Lovely Systems
made during the last 12 month in stealth mode.
We're using heavily WSGI and are replacing ZODB within most of our
applications.
Tomorrow we're leaving to New York visiting our friend reco. dobee and I
will be working on getting the component architecture running on AppEngine.
Later next week we'll fly to San Francisco to attend Google I/O and get
even more insight to the technology.
We're open to release lovely.nozodb and the related components in near
future, as usual - just some polishing missing…
Please drop me a note ([EMAIL PROTECTED], batlogg on skype/AIM) or
give me a call (+43 664 9636963) if you want to join us.

jodok
--
Lovely Systems, Partner

phone: +43 5572 908060, fax: +43 5572 908060-77
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria

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





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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope3 on Google AppEngine

2008-05-23 Thread David Pratt
Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, 
this is much closer to what integration ought to look like for CA. BTW, 
I noticed that z3c.dobbin is zpl but ore.alchemist that it depends on is 
gpl. I think all the other zope flavors of sqlalchemy are under zpl. I 
believe there was a recent effort to bring the sqlalchemy flavors 
together under a single package. Not sure what progress has been made.


In any case, this direction looks like a good one. It would be 
interesting if dobbin could map for storm but it appears to rely heavily 
upon ore.alchemist. I believe storms advantage is that it is faster than 
sqlalchemy since it doesn't have to worry about pooling connections, 
mappers, and more.  I'd be interesting to see a similar approach with 
storm. Good job on this.


Regards,
David

Malthe Borch wrote:

David Pratt wrote:
Hi Jodok. I had looked at storm a while back but the zope integration 
seemed to lack any relationship with zope schemas.  I guess it is 
possible to define a zope schema that is not persisted and create the 
tables from it. It did not seem to me a good way of using CA. How are 
you managing this part of things.


fwiw, ore.alchemist and now z3c.dobbin integrates zope.interface and 
zope.schema with sqlalchemy, each taking a quite different approach.


\malthe

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



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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope3 on Google AppEngine

2008-05-23 Thread David Pratt
Hi Malthe. Perhaps I am wrong about the licensing situation. I guess its 
a bit confusing since pypi indicates GPL and package ZPL. I guess I 
should contact Kapil for clarification if I am interested in 
experimenting here. Many thanks.


Regards,
David

name=ore.alchemist,
version=0.5.1,
url=http://code.google.com/p/zope-alchemist;,
install_requires=['setuptools', 'transaction'],
packages=find_packages('src', exclude=[*.tests]),
package_dir= {'':'src'},
namespace_packages=['ore'],
package_data = {
'': ['*.txt', '*.zcml', '*.pt'],
},
zip_safe=False,
author='Kapil Thangavelu',
author_email='[EMAIL PROTECTED]',
description=\
ore.alchemist contains an integration of sqlalchemy into the
Zope App server environment. It can be used with Zope2, Zope3 or
standalone.
,
license='ZPL',
keywords=zope zope3,
)

Malthe Borch wrote:

David Pratt wrote:
Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, 
this is much closer to what integration ought to look like for CA. 
BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that it 
depends on is gpl. I think all the other zope flavors of sqlalchemy 
are under zpl. I believe there was a recent effort to bring the 
sqlalchemy flavors together under a single package. Not sure what 
progress has been made.


It's progressing, but we've also talked to Kapil about relicensing 
ore.alchemist to LGPL or ZPL, whichever is enough.


In any case, this direction looks like a good one. It would be 
interesting if dobbin could map for storm but it appears to rely 
heavily upon ore.alchemist.


I think it's more accurate to say that both rely heavily on SQLAlchemy. 
We're actually not using the table reflection functionality of 
ore.alchemist because we've taken a different approach to it (joining on 
minimal interfaces rather than mapping classes to tables). What we are 
using is some of the zope.schema to sqlalchemy.Column mappings and the 
database session environment.


I believe storms advantage is that it is faster than sqlalchemy since 
it doesn't have to worry about pooling connections, mappers, and 
more.  I'd be interesting to see a similar approach with storm. Good 
job on this.


Thanks, I think we might've found a good approach. Currently we're 
test-driving it in the Vudo project. So far so good.


I don't know much about storm; at this point I must say that I care more 
about ease of use, mindshare and stability than just speed; we feel that 
SQLAlchemy gives us that. Add to it that their community is absolutely 
great.


\malthe

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



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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope3 on Google AppEngine

2008-05-23 Thread David Pratt
Hi Malthe. Kapil has confirmed the licensing is ZPL with a version bump 
to 0.5.2 with a change in the headers, etc. I am anxious to experiment 
with dobbin since it looks so straight forward and nice. I guess I see 
traversal and containers as possible issues but will be interested in 
potential solutions. Trails for grok is one possible solution for 
traversal but will be curious to see approaches for replacing containers.


Regards
David

David Pratt wrote:
Hi Malthe. Perhaps I am wrong about the licensing situation. I guess its 
a bit confusing since pypi indicates GPL and package ZPL. I guess I 
should contact Kapil for clarification if I am interested in 
experimenting here. Many thanks.


Regards,
David

name=ore.alchemist,
version=0.5.1,
url=http://code.google.com/p/zope-alchemist;,
install_requires=['setuptools', 'transaction'],
packages=find_packages('src', exclude=[*.tests]),
package_dir= {'':'src'},
namespace_packages=['ore'],
package_data = {
'': ['*.txt', '*.zcml', '*.pt'],
},
zip_safe=False,
author='Kapil Thangavelu',
author_email='[EMAIL PROTECTED]',
description=\
ore.alchemist contains an integration of sqlalchemy into the
Zope App server environment. It can be used with Zope2, Zope3 or
standalone.
,
license='ZPL',
keywords=zope zope3,
)

Malthe Borch wrote:

David Pratt wrote:
Hi Malthe. z3c.dobbin looks quite good and transparent. In my 
opinion, this is much closer to what integration ought to look like 
for CA. BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that 
it depends on is gpl. I think all the other zope flavors of 
sqlalchemy are under zpl. I believe there was a recent effort to 
bring the sqlalchemy flavors together under a single package. Not 
sure what progress has been made.


It's progressing, but we've also talked to Kapil about relicensing 
ore.alchemist to LGPL or ZPL, whichever is enough.


In any case, this direction looks like a good one. It would be 
interesting if dobbin could map for storm but it appears to rely 
heavily upon ore.alchemist.


I think it's more accurate to say that both rely heavily on 
SQLAlchemy. We're actually not using the table reflection 
functionality of ore.alchemist because we've taken a different 
approach to it (joining on minimal interfaces rather than mapping 
classes to tables). What we are using is some of the zope.schema to 
sqlalchemy.Column mappings and the database session environment.


I believe storms advantage is that it is faster than sqlalchemy since 
it doesn't have to worry about pooling connections, mappers, and 
more.  I'd be interesting to see a similar approach with storm. Good 
job on this.


Thanks, I think we might've found a good approach. Currently we're 
test-driving it in the Vudo project. So far so good.


I don't know much about storm; at this point I must say that I care 
more about ease of use, mindshare and stability than just speed; we 
feel that SQLAlchemy gives us that. Add to it that their community is 
absolutely great.


\malthe

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



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



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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope3 on Google AppEngine

2008-05-22 Thread David Pratt
Hi Jodok. Sounds interesting. Curious what you are replacing ZODB with. 
Are you using its interfaces to Relstorage / other ZODB backend, an ORM 
to map direct to rdb, or other database. Many thanks.


Regards,
David

Jodok Batlogg wrote:

Hi,

Next week Lovely will be sprinting in New York/San Francisco to get the 
Zope3 framework and the first applications running on Google AppEngine. 
You’re welcome to join us.
Google AppEngine is a perfect match to the transition we at Lovely 
Systems made during the last 12 month in “stealth mode”.
We’re using heavily WSGI and are replacing ZODB within most of our 
applications.
Tomorrow we’re leaving to New York visiting our friend reco. dobee and I 
will be working on getting the component architecture running on AppEngine.
Later next week we’ll fly to San Francisco to attend Google I/O and get 
even more insight to the technology.
We’re open to release lovely.nozodb and the related components in near 
future, as usual - just some polishing missing…
Please drop me a note ([EMAIL PROTECTED], batlogg on skype/AIM) or 
give me a call (+43 664 9636963) if you want to join us.


jodok
--
Lovely Systems, Partner

phone: +43 5572 908060, fax: +43 5572 908060-77
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria

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



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

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Building on python 2.5 - any progress?

2008-05-08 Thread David Pratt
Hi. I am wondering if there was any further resolution to builds with 
python 2.5 as discussed in the following articles:


http://mail.zope.org/pipermail/zope3-users/2007-September/006909.html
http://mail.zope.org/pipermail/zope3-users/2007-September/006916.html

In addition to the warnings concerning initialization from incompatible 
pointer type, there are numerous warnings about intargfunc and 
intintargfunc being deprecated also.


I am building on mac osx and run into these issues also. I am becoming a 
bit more concerned about moving to 2.5 as opposed to 2.4 for my work. 
Anyone building on a platform that has not posed this problem. Any 
compiler flags to python or recommendation for a different compiler that 
may help with this. Many thanks.


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: new zope.org, sphinx, and documentation management

2008-04-26 Thread David Pratt
Hey Paul. It's definitely something I want, so will examining this 
further and let you know if I come up with something.


Regards,
David

Paul Carduner wrote:

On Fri, Apr 25, 2008 at 5:48 AM, David Pratt [EMAIL PROTECTED] wrote:

Hi Paul. Good work. Personally, I am interested in switching out the jinja
templates for zpt or ctal since am not that keen about mixing template
languages for myself. It looks like the more recent changes to sphinx should
accommodate this with the template_bridge but have yet to investigate this
further.


I agree with you that using zpt would be more preferable.  At this
point though I don't think we have an immediate need for it.  The only
change I made to the sphinx default template was adding some static
html for the zope branding.  Eventually though, if we want to build a
more robust documentation build tool with direct zope integration, zpt
would be absolutely necessary.  But if you are volunteering to
research using the template bridge, I'd be happy to use whatever you
come up with.

- Paul

--
Paul Carduner
http://www.carduner.net


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: new zope.org, sphinx, and documentation management

2008-04-26 Thread David Pratt
Hi Paul. For what it's worth, here's what I am doing which seems to 
work without a new recipe at this point. The rest should be just the 
overrides for the templates I believe but not what else you are doing 
with your docs.


1. Create a docs/html folder in my buildout
2. Add the following sphinx part
3. run ./bin/sphinx-quickstart (use all the defaults - no make file though)
4. run ./bin/sphinx-build -b html -d .build/doctrees . docs/html

Regards,
David


[buildout]
versions = versions
parts = sphinx
log-level = DEBUG

[versions]
Sphinx = 0.1.61950
Pygments = 0.9

[sphinx]
recipe = zc.recipe.egg
scripts = sphinx-quickstart
  sphinx-web
  sphinx-build
eggs = Sphinx
   docutils
   Pygments




David Pratt wrote:
Hey Paul. It's definitely something I want, so will examining this 
further and let you know if I come up with something.


Regards,
David

Paul Carduner wrote:
On Fri, Apr 25, 2008 at 5:48 AM, David Pratt [EMAIL PROTECTED] 
wrote:
Hi Paul. Good work. Personally, I am interested in switching out the 
jinja

templates for zpt or ctal since am not that keen about mixing template
languages for myself. It looks like the more recent changes to sphinx 
should
accommodate this with the template_bridge but have yet to investigate 
this

further.


I agree with you that using zpt would be more preferable.  At this
point though I don't think we have an immediate need for it.  The only
change I made to the sphinx default template was adding some static
html for the zope branding.  Eventually though, if we want to build a
more robust documentation build tool with direct zope integration, zpt
would be absolutely necessary.  But if you are volunteering to
research using the template bridge, I'd be happy to use whatever you
come up with.

- Paul

--
Paul Carduner
http://www.carduner.net


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


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: new zope.org, sphinx, and documentation management

2008-04-25 Thread David Pratt
Hi Paul. Good work. Personally, I am interested in switching out the 
jinja templates for zpt or ctal since am not that keen about mixing 
template languages for myself. It looks like the more recent changes to 
sphinx should accommodate this with the template_bridge but have yet to 
investigate this further.


Regards,
David

Paul Carduner wrote:

After a fair amount of work figuring out Sphinx, I modified the
default css and template to produce something that could be more or
less seemlessly integrated into the new zope.org.  Anyhow, I encourage
everyone to take a look at http://docs.carduner.net/z3c.form/ for a
working example.  This weekend I hope to make a buildout recipe that
does all this in a more magical way.

- Paul

--
Paul Carduner
http://www.carduner.net
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce

 http://mail.zope.org/mailman/listinfo/zope )


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: new zope.org, sphinx, and documentation management

2008-04-24 Thread David Pratt
Hi Paul. This is beautiful. A recipe is what we need now. Send me a mail 
off list if you want some help with this.


Regards,
David

Kent Tenney wrote:

On Thu, Apr 24, 2008 at 2:09 AM, Paul Carduner [EMAIL PROTECTED] wrote:

On Wed, Apr 23, 2008 at 10:48 PM, Paul Carduner [EMAIL PROTECTED] wrote:
  On Wed, Apr 23, 2008 at 12:01 PM, Martin Aspeli [EMAIL PROTECTED] wrote:


   I would start with the simple HTML approach, personally. It may be all we

need.
 
   Hopefully there will be a first sample of this in the next hour or so.
 

 Ok, I setup a sample of what sphinx produces after a quite minimal
 setup for z3c.form.  Check it out at:
 http://docs.carduner.net/z3c.form/.  I made a few small modifications
 to the existing documentation, which I checked into a branch on
 svn.zope.org along with the sphinx setup generated for me by the
 sphinx-quickstart command.  A few goody features include:

 Full text searching powered by javascript:
 http://docs.carduner.net/z3c.form/search.html
 Module index with quick synopses:
 http://docs.carduner.net/z3c.form/modindex.html (click on the plus
 symbol after the big Z)
 Cross links to other parts of the documentation:
 http://docs.carduner.net/z3c.form/src/z3c/form/README.html

 So far, I think this is pretty good for what took me maybe an hour.
 Think of what it would be with some extra documentation cleanup.


Cool!.

The Zope-3.3.1 tree contains 70 README.txt,  309 *.txt

so, more than 70 files of correct, up to the minute examples of use.
That's a lotta doc.

If not adequate in themselves, invaluable as link
destinations when explaining with prose.

As they grow
..contents::
directives, and more section headings are added, glossary tags are added,
they will increase in value.





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


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

 http://mail.zope.org/mailman/listinfo/zope )


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

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Annoying: Download error: unknown url type: svn -- Some packages may not be found!

2008-04-16 Thread David Pratt
Which package is emitting the Download error: unknown url type: svn -- 
Some packages may not be found! Its quite annoying and I have been 
seeing it crop up in a few builds. Anyone else seeing this. Many thanks.


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

http://mail.zope.org/mailman/listinfo/zope )


Re: AW: [Zope-dev] Annoying: Download error: unknown url type: svn -- Some packages may not be found!

2008-04-16 Thread David Pratt
Hi Roger. I turned on debug and increased verbosity. z3c.template and 
z3c.form seem to be the culprits. Getting 4 of these warnings on 
z3c.template and 1 with z3c.form between the getting ... and picked ... 
notices. Not quite sure why they are emitting the warnings. Can't find 
the error in buildout so must be in setuptools somewhere. I would expect 
to see an svn address in setup.py or something based on what message is 
saying - nothing like this that I can see.


This was reported on the zope users list without a response a little 
while back as well:


http://www.mail-archive.com/[EMAIL PROTECTED]/msg06448.html

Regards,
David

Roger Ineichen wrote:

Hi David
 
Betreff: [Zope-dev] Annoying: Download error: unknown url 
type: svn -- Some packages may not be found!


Which package is emitting the Download error: unknown url 
type: svn -- Some packages may not be found! Its quite 
annoying and I have been seeing it crop up in a few builds. 
Anyone else seeing this. Many thanks.


I see this too. Try the buildout debug option, probably this
will you give a better output.

Regards
Roger Ineichen
_
END OF MESSAGE


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

 http://mail.zope.org/mailman/listinfo/zope )




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

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] A permanent log for buildouts

2008-04-14 Thread David Pratt
Has anyone already setup a more permanent log for buildouts. I am 
wanting a more permanent record of what has happened when buildout is 
run. I believe this likely ought to be part of zc.buildout so that you 
identify a buildout.log location. Many thanks.


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] A permanent log for buildouts

2008-04-14 Thread David Pratt
Hi Jim. Yes, I definitely want a logging configuration also. I'm at 
least hoping to look into the logging setup in the next couple of days 
in between some other things. Many thanks.


Regards,
David

Jim Fulton wrote:


On Apr 14, 2008, at 12:39 PM, David Pratt wrote:
Has anyone already setup a more permanent log for buildouts. I am 
wanting a more permanent record of what has happened when buildout is 
run. I believe this likely ought to be part of zc.buildout so that you 
identify a buildout.log location. Many thanks.



There isn't anything like this now.  I'd be in favor of something.  All 
that might be needed is to provide a way to specify a python logger 
configuration.  IMO, it would be enough to provide an option to name a 
logger config file as described in:


  http://docs.python.org/lib/logging-config-fileformat.html

You might be able to arrange this now using the buildout extension 
mechanism:


  http://pypi.python.org/pypi/zc.buildout#extensions

Jim

--
Jim Fulton
Zope Corporation



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

http://mail.zope.org/mailman/listinfo/zope )


Re: AW: [Zope-dev] Status of zam packages

2008-04-08 Thread David Pratt
Hi Roger. Thank you for this update. I will continue to work with these 
but will be aware that they are a bit volatile at the moment. 
Personally, I hope you don't remove the dependency upon the z3c.table 
and z3c.contents packages since these views add value. I think it would 
be better to include them but just allow folks to make that decision 
when they create a custom skin.


Regards,
David

Roger Ineichen wrote:

Hi David, Chris
 

Betreff: Re: [Zope-dev] Status of zam packages

zam (zope application manager) is reimplementation of sorts 
of the z3 zmi using a pagelet and form layers and with a 
plugin architecture and api. I have been working with it a 
bit but not sure how stable the api is so that I can build 
upon it which is what I am doing.


Give me another two weeks and I hope to get ready for a 
initial release. Some tests break right now because

I added a contets.html view which depends on z3c.table
and z3c.contents. I think I will skip that dependency since 
probably not everybody will use zc.table or z3c.contents


Darryl also did some improvments on a branch of z3c.contents
which we need to merge back before we do a release.

If this is done, ZAM should be stable enough for production.

Regards
Roger Ineichen



Chris Withers wrote:

David Pratt wrote:
I am hoping I can get a bit of an update on zam packages 
on zope svn. 

Many thanks.

What is zam?

Chris


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

 http://mail.zope.org/mailman/listinfo/zope )




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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Status of zam packages

2008-04-07 Thread David Pratt
zam (zope application manager) is reimplementation of sorts of the z3 
zmi using a pagelet and form layers and with a plugin architecture and 
api. I have been working with it a bit but not sure how stable the api 
is so that I can build upon it which is what I am doing.


Chris Withers wrote:

David Pratt wrote:
I am hoping I can get a bit of an update on zam packages on zope svn. 
Many thanks.


What is zam?

Chris


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Let's fix the damned website

2008-04-05 Thread David Pratt
Hi Martin. I would like to help with Zope 3 but could not commit to 
championing the effort as much as I might like to due to time 
constraints. I am prepared to write some articles, help with an 
introduction, or help review in conjunction with someone leading the 
Zope 3 effort. Are any of the lovely or zope corp folks on the z3 side 
willing to champion or participate? Is there an outline somewhere that I 
can determine something concrete to work on? Let me know. I like the 
design BTW and this is definitely a good news development.


Regards,
David

Martin Aspeli wrote:

Hi all,

The rumours are true. :) An effort has been going on for a while to 
improve the zope.org experience and thereby help make Zope more 
accessible to new users.


I've helped co-ordinate it, but the project has been sanctioned by the 
Zope Foundation and driven by people like Martijn, Philipp, Wichert and 
others. Given Martijn's excellent blog post today 
(http://faassen.n--tree.net/blog/view/weblog/2008/04/05/0) and recent 
progress we've made, I thought it timely to open up and ask for your help.


Here's what we have achieved so far:

 - A great design by Oliver Ruhm, paid for by Lovely Systems
 - A Plone 3 site hosted by Lovely Systems
 - A skin for this site by Denis Mishunoff
 - A skeleton content structure
 - A plan for going forward

Now we need people to help contribute content, review the content that's 
already there and tie up a few loose ends.


You can see current state of play here: http://zode01.lovelysystems.com.

The original design mockups from Oliver are here: 
http://woimmer.com/presenter/zope.org/1.html


We have agreed a plan going forward with the Zope Foundation. Basically, 
we want to move the current zope.org off into a separate domain, e.g. 
old.zope.org. We explicitly do not want to port existing content from 
zope.org wholesale, because (a) most of it's out of date and (b) this 
would be a huge effort. We'll need to provide some aliases for downloads 
that people (and buildouts) expect to find on zope.org, but this can be 
managed using Plone's RedirectionTool.


We also want to start small. Some things, like planet.zope.org, 
wiki.zope.org and foundation.zope.org stay where they are for now. 
Existing documentation should be ported over manually, and subject to 
quality and relevancy review in the process.


We want to tackle the external face of Zope first. Membership of the 
site will be by invitation (i.e. ask me and I'll give you an account), 
for content authors only. We don't want to allow arbitrary home 
folders - at least not just yet. Again, some things probably need to be 
moved over, but there is too much cruft on the old zope.org to move it 
wholesale.


There has been a lot of discussion around the message we want to send. 
The current zope.org is quite confusing to people who are not familiar 
with the intricate history of Zope. In short, the message we want to 
project is:


 - Zope is an established, mature, enterprise ready project

 - If you don't know where to start, start with Grok (note that Grok has 
its own website, which we link to when relevant)


 - There is a common framework that unites Zope 2, Zope 3 (the app 
server) and Grok. We often call this Zope 3 internally, but for the 
purposes of explanation, we will try to refer to the core web 
application libraries as the Zope Libaries.


 - We want to frame the ZODB as something that can be used without Zope 
as well as an integral part of Zope


To that end, the website is divided up into sections:

 - Home gives a quick overview and tries to get people excited

 - Get gives download instructions for the impatient

 - Taste whets the reader's appetite with some exciting code examples 
that explain how Zope is different


 - Projects gives an explanation of how the different Zope projects 
fit together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a 
subfolder that contains a standard structure: A front page that explains 
the project in more detail, Get (downloads), Taste (as above, but 
for a particular project) and Learn. The Learn section should 
contain relevant, up-to-date documentation.


 - Community gives some details about how to join the Zope community

 - Foundation links to the Foundation site for now. If the Foundation 
website maintainers want to move into this site in the future, they are 
of course more than welcome to.


Now, you'll notice that a lot of content is missing! This is where we 
need volunteers.


  o Critical reviewer -- I would like someone to review the text on
the site from time to time and offer feedback on clarity, style,
consistency and message. This person may either act as editor and change
things on the fly, or just ask the relevant author to change something.
Ideally, this is someone with an opinion on Zope as a whole and its
place in the world. Jan Ulrich Hasecke has volunteered for this. I think 
we may need two or three people for this role, though.


  o Get section 

[Zope-dev] Status of zam packages

2008-04-03 Thread David Pratt
I am hoping I can get a bit of an update on zam packages on zope svn. 
Many thanks.


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [Zope3-Users] How do I automatically login a user

2008-04-03 Thread David Pratt
Thanks Jim for doing this. Actually, the domain is something I have been 
looking for also. These other features are really nice. I am hoping this 
 can be worked into something like z3c.authentication for generic use. 
Hoping roger is following this.


Regards,
David

Jim Fulton wrote:


Let's move this discussion to zope-dev.

On Apr 2, 2008, at 5:36 AM, kevin gill wrote:

Please check in the code to the sandbox and I will have a look at it. The
coding looks straight-forward, but choosing how to work it into the
existing  components.

I will look at the code and come back with questions.



I just checked 2 files, session.txt and session.py, into

  http://svn.zope.org/Sandbox/J1m/

These provide several features, most of which are of particular interest 
here:


- An api to save session credentials independent of login,

- saving sha-encoded passwords,

- logout api

- having an optional additional credential of a user domain,
  (probably not of general interest)

Jim

--
Jim Fulton
Zope Corporation


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


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Reducing dependencies of zope.publisher

2008-03-21 Thread David Pratt
Hi Jim. What does this mean? Will the new package be a drop in 
replacement for what we have without some direction on what to do with 
the other bit or will it break our applications. A working publisher is 
pretty essential to a functioning zope app. Does this mean the end of 
deprecation warnings for the publisher? Is this not useful? Many thanks.


Regards,
David


Jim Fulton wrote:


I'd like reduce the barrier of entry for using the Zope 3 zope 
publisher.  Right now, it has quite a few dependencies setuptools, 
zope.component, zope.event, zope.exceptions, zope.i18n, zope.interface, 
zope.location, zope.proxy, zope.security, zope.deprecation, and 
zope.deferredimport.   This seems a bit extreme.  I can get rid of 
zope.deprecation and zope.deferredimport directly.  I'd like to get rid 
of more.


I'm thinking of creating a separate package that contains much of the 
guts of zope.publisher, but without most or all of the existing 
dependencies.  I'd then modify zope.publisher to import code from this 
other package, adding the bits that exist now that cause the dependencies.


This new package would a number of things, including skin support, 
xmlrpc support, mapply, interface declarations and various view base 
classes that now live in zope.publisher.


Thoughts? Objections?

Jim

--
Jim Fulton
Zope Corporation


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


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Reducing dependencies of zope.publisher

2008-03-21 Thread David Pratt
Hi Jim. OK great. Many thanks for elaborating. This will be progressive. 
I had been considering an application use case without a zodb. Is this 
the scenario that the basic publisher would facilitate?


Regards,
David

Jim Fulton wrote:


On Mar 21, 2008, at 12:10 PM, David Pratt wrote:


Hi Jim. What does this mean?


It wouldn't have any visible effect on zope.publisher. Applications that 
use zope.publisher wouldn't see a change.


There would be an alternative to zope.publisher that has far fewer 
dependencies and fewer features.  zope.publisher would build on this 
lower-level thing.  The low-level package would be well suited to people 
who want to build small web applications with Python.  As people have 
more requirements, they might graduate from the smaller framework to 
zope.publisher.


Jim

--
Jim Fulton
Zope Corporation



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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.

2008-03-11 Thread David Pratt
Hi Andreas. I think your response gets to the heart of the issue. For 
software to be useful, it is often more important for folks other than 
the author to understand it. This can only occur with communication. 
Sometimes it is the understanding of edgecases in particular, that gets 
lost over time. I find generally that I cannot keep in memory all of the 
details of the code I write. Several months afterwards without my own 
documentation, these details can be lost. So it is just important if I 
need to come back to it myself as for anyone else.


If the test is worth writing, it is not difficult to add a small amount 
of text to communicate about it. If the software is worth writing in the 
first place, I consider the code incomplete without doctests. For 
community projects, it is often the case that it is not the author 
maintaining the code in the future. This only strengthens the argument 
for doctests and the reason this has become the standard for zope.


Regards,
David



Andreas Jung wrote:

usage of your module. It's basically not of interest for telling them 
all edgecases. Addressing edgecase is unittests is basically good enough 
for me. They sometime require more code to test and put this into a 
doctest is often just overhead.


Andreas




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

 http://mail.zope.org/mailman/listinfo/zope )

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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildout-based buildbot back

2008-03-05 Thread David Pratt
Thanks Christian. I am interested in this. Are there significant changes 
to what you are doing now? I'll checkout what you have in the Sandbox in 
the interim. Many thanks.


Regards,
David

Christian Theune wrote:

Hi,

David Pratt schrieb:
Hi Christian. How difficult was this to get running. I am considering 
a a local buildbot for my own code. The structure of my repository 
emulates the structure of svn.zope.org. Many thanks.


Semi-hard. The actual buildout configuration script and repository 
sniffing took some time. I'm not sure I checked this configuration in, 
but I'm holding a previous version in my Sandbox on zope.org.


Christian


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildout-based buildbot back

2008-03-04 Thread David Pratt
Hi Christian. How difficult was this to get running. I am considering a 
a local buildbot for my own code. The structure of my repository 
emulates the structure of svn.zope.org. Many thanks.


Regards,
David

Christian Theune wrote:

Hi,

it took a while, but here it is: I've put the buildout-based buildot 
into its own virtual machine (with enough resources hopefully).


It's been running for about a week now and seems to work fairly well. I 
integrated the classical buildbot view and my alternative display in one 
installation that is accessible at:


http://zopebuildout.whq.gocept.com

- builds are run when the trunk of a buildout-based project is changed
  and at 3am CEST every day.

- Updates for the project list are run before the nightly build and pick
  up all projects' trunks that define a buildout.cfg

- Currently, all projects that don't define a test runner will appear as
  broken. I'll fix that soon so that non-existing test runners will be
  ignored.

Christian


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: buildout 'versions' and 'develop' conflict

2008-02-25 Thread David Pratt
Hi Martijn. I respect the points you make, but disagree with your 
comments. Wichert's reply accurately articulates what we are asking 
buildout to do. I share this view.


On a personal note, I tend to rely on my own version lists but refer to 
the online lists (for support in creating them). On explicit vs 
implicit, it is debatable any time you consider incorporating implicit 
behaviour.


When you make the point about versions duplication, you may not be 
considering the utility of buildout. In fact, a buildout does not 
require a setup.py at all. setup.py is only a requirement for packaging 
in python. Buildout is already being used together with other packaging 
solutions and in other ways as I have previously mentioned. Overall, 
buildout cfg files are an abstraction. Its most attractive features are 
that it is simple, readable, fairly well documented and without a great 
deal of obfuscation or magic. You may consider a recipe and utility 
script that uses versions to help build a setup.py. It would seem more 
in line with the character of the software.


Regards,
David


Martijn Faassen wrote:

David Pratt wrote:
Hi. I agree with Jim. Buildout is doing the right thing. This is not a 
conflict since you have explicitly identified the software with a 
version already. I think the right thing to do under the circumstances 
would be to append a custom versions.cfg to nail the versions you 
want. KGS versions is a point in time list and it does not apply to 
the full scope of what buildout is being used for. I believe this 
should be kept in mind since it serves more than z3.


Changes to buildout to have it automatically do the 'right' thing 
opens the implicit versus explicit argument. A developer would then 
need to be aware of the implicit cases that would cause a different 
software selection. Much like zcml configuration in zope, I want to 
tell buildout what to do and have it do it without surprise (or for 
that matter fighting any implicit nature folks may be inclined to give 
it). While I understand the concern about the development egg for your 
build, I would see any move in this direction as corrupting the nature 
of buildout to 'do what you have told it to do'


I want to tell buildout what to do have it do it without surprise as 
well. I was surprised when it didn't do what I expected: give priority 
to the develop package. Why else would I choose to put it on the develop 
line?


I take it you have run into this and weren't surprised at all, then?

I think the explicit versus implicit discussion has no place here. 
Placing a package on the 'develop' line is a very explicit action, and 
you place it on that line because you want to *develop on it*. Having 
another package being picked up is surprising.


I realize that it has a reason: it does what you tell it do. But lists 
of locked versions are things that are frequently maintained offline - 
even sitting off on some URL, and maintained by someone else. Yes, 
indirectly you are telling buildout about versions, but you may not be 
very aware of it. These are long lists, after all. It'd be nice if these 
lists could be treated as mostly opaque (encapsulation) and that you can 
simply look at what's in setup.py instead.


That is not possible now. You need to *know* that it lists the package 
you are trying to hack on, and you need to know that you need to add it 
to [versions]. The workaround I find myself using frequently now is this:


[versions]
the_package =

I don't see the point when I already say this in 'develop'.

Regards,

Martijn

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


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildout 'versions' and 'develop' conflict

2008-02-23 Thread David Pratt
Hi. I agree with Jim. Buildout is doing the right thing. This is not a 
conflict since you have explicitly identified the software with a 
version already. I think the right thing to do under the circumstances 
would be to append a custom versions.cfg to nail the versions you want. 
KGS versions is a point in time list and it does not apply to the full 
scope of what buildout is being used for. I believe this should be kept 
in mind since it serves more than z3.


Changes to buildout to have it automatically do the 'right' thing opens 
the implicit versus explicit argument. A developer would then need to be 
aware of the implicit cases that would cause a different software 
selection. Much like zcml configuration in zope, I want to tell buildout 
what to do and have it do it without surprise (or for that matter 
fighting any implicit nature folks may be inclined to give it). While I 
understand the concern about the development egg for your build, I would 
see any move in this direction as corrupting the nature of buildout to 
'do what you have told it to do'.


Regards,
David


Jim Fulton wrote:


On Feb 23, 2008, at 9:26 AM, Christophe Combelles wrote:
I don't have enough experience with all the use cases of buildout and 
the develop-eggs, but at a first glance, I find it more logical to 
give priority to 'develop':
'develop' is supposed to point to a real path containing a setup.py, 
so when defining a develop-egg, you clearly indicate that you want 
*that* path, whathever version this develop-egg defines.


That is the philosophy that buildout takes. That's why, when picking 
versions, buildout prefers develop eggs over newer non-develop eggs.  
However, buildout will only use a develop egg if it satisfies stated 
requirements.  As it stands today, specifying a version in a versions 
section is like stating a == requirement in a setup script or in a eggs 
option.


Jim

--
Jim Fulton
Zope Corporation


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


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildout 'versions' and 'develop' conflict

2008-02-23 Thread David Pratt
Hi Christophe. Wichert has just responded with the point I was going to 
make in reply. I can agree with your point that emitting warnings are 
helpful for misconfiguration or if there has been duplication. I am 
opposed to incorporating the type of automatic character that has been 
suggested.


Regards,
David

Christophe Combelles wrote:

David Pratt a écrit :
Hi. I agree with Jim. Buildout is doing the right thing. This is not a 
conflict since you have explicitly identified the software with a 
version already. I think the right thing to do under the circumstances 
would be to append a custom versions.cfg to nail the versions you 
want. KGS versions is a point in time list and it does not apply to 
the full scope of what buildout is being used for. I believe this 
should be kept in mind since it serves more than z3.


Changes to buildout to have it automatically do the 'right' thing 
opens the implicit versus explicit argument. A developer would then 
need to be aware of the implicit cases that would cause a different 
software selection. Much like zcml configuration in zope, I want to 
tell buildout what to do and have it do it without surprise (or for 
that matter fighting any implicit nature folks may be inclined to give 
it). While I understand the concern about the development egg for your 
build, I would see any move in this direction as corrupting the nature 
of buildout to 'do what you have told it to do'.



Hi,

I don't think this is a matter of implicit versus explicit, because 
there are two explicit configurations: one explicit 'version', and one 
explicit 'develop'.
I think the question is about what to choose between two explicit 
configurations that are potentially conflicting.


There can be arguments for giving priority on one of them.
Maybe the best thing here would be to just warn the user (in stdout) 
about the conflict. Buildout should tell him that either the specified 
version won't be used, or the develop-egg won't be used.


regards
Christophe




Regards,
David


Jim Fulton wrote:


On Feb 23, 2008, at 9:26 AM, Christophe Combelles wrote:
I don't have enough experience with all the use cases of buildout 
and the develop-eggs, but at a first glance, I find it more logical 
to give priority to 'develop':
'develop' is supposed to point to a real path containing a setup.py, 
so when defining a develop-egg, you clearly indicate that you want 
*that* path, whathever version this develop-egg defines.


That is the philosophy that buildout takes. That's why, when picking 
versions, buildout prefers develop eggs over newer non-develop eggs.  
However, buildout will only use a develop egg if it satisfies stated 
requirements.  As it stands today, specifying a version in a versions 
section is like stating a == requirement in a setup script or in a 
eggs option.


Jim

--
Jim Fulton
Zope Corporation


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







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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 3 without ZODB

2008-02-15 Thread David Pratt
Cool Jim. Will take a look and read. This is what the wonderful world of 
packages and wsgi is all about :-). I am also going to check out Kapil's 
solution for some other things. I am pretty comfortable with the zope's 
publisher and configuration.


Regards,
David

Jim Washington wrote:

Kapil Thangavelu wrote:
try ore.wsgiapp in pypi, you provide a root utility and traversal 
begins from there, the zodb is never opened. the default publication 
looks up the app root via utility and traversal continues from there. 
i've been using it successfully for a number of relational apps 
without the zodb.

Thanks, Kapil.

I spent a day on it, and never got past error pages.  Maybe my problem 
was starting with a zopeproject.


Anyway, it got me to take a good look at pylons, which I think is a 
better match for web development without ZODB.


I found I can still use adapters and utilities by using zope.component 
and zope.interface. :)


zif.sedna (newly beta2 in pypi) now has instructions for using its zope3 
database adapter with repoze.tm in pylons.


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


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 3 without ZODB

2008-02-15 Thread David Pratt
Hi Kapil. Hoping to take a look at this before long. Many thanks for 
pointing out this package.


Regards,
David

Kapil Thangavelu wrote:
try ore.wsgiapp in pypi, you provide a root utility and traversal begins 
from there, the zodb is never opened. the default publication looks up 
the app root via utility and traversal continues from there. i've been 
using it successfully for a number of relational apps without the zodb.


hth,

kapil

On Jan 15, 2008 1:27 PM, Jim Washington [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


David Pratt wrote:
  Hi Chris. I was scanning the lists looking for posts similar to this.
  Were you successful in getting something like this to work? Anyone
  else document anything like this?
 
  I wrote a different main.py at some point about a year or so ago so
  both twisted clients and servers to could be started up using schemas
  for zconfig but am looking at possibilities without and with
other non
  ZODB backends. I see Philip provided some clues for a mixin that
could
  be used to glue the publisher's traversal mechanism together with an
  alternative storage.  Many thanks.
 
  Regards,
  David
I, too, am interested in this.

I'm taking a hard look at Sedna, http://modis.ispras.ru/sedna/ , a
multi-user XML database, which seems to fit my brain and my current
xml-ish bent a bit better than ZODB or rdb.

The python modules advertised don't work reliably enough for me, though
I have hacked together a protocol module that works to my satisfaction
so far.  If anyone wants to play with it, I'll throw it into the zif
collective on Sourceforge.  I'm thinking it may be possible to do an
elementtree (with full XPath!) interface to Sedna.

Anyway, Chris, any pointers on interfaces and configuration would be
very much appreciated.

-Jim Washington




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



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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope 3 without ZODB

2008-02-15 Thread David Pratt
Hi Tres. Appreciate your reply. I examine the packages you have 
identified. Many thanks.


Regards,
David

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Pratt wrote:
Cool Jim. Will take a look and read. This is what the wonderful world of 
packages and wsgi is all about :-). I am also going to check out Kapil's 
solution for some other things. I am pretty comfortable with the zope's 
publisher and configuration.


For another take, 'repoze.obob'[1] exposes a hook for starting traversal
from an arbitrary root object:  'repoze.kiss'[2] uses this hook, along
with the Zope2 publisher as re-worked in 'repoze.zope2', to publish
content from a filesystem directory.

To test drive:

 $ bin/virtualenv /tmp/kiss
 $ cd /tmp/kiss
 $ bin/easy_install repoze.project
 $ bin/repozeproject repoze.kiss
 $ cp $SITE_PACKAGES/repoze.kiss-*/sample-repoze.ini ./kiss.ini
 $ vi kiss.ini # edit to point to a path
 $ bin/paster serve kiss.ini



[1] http://svn.repoze.org/repoze.obob/trunk/

[2] http://svn.repoze.org/repoze.kiss/trunk/

[3] http://svn.repoze.org/repoze.zope2/trunk/



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

iD8DBQFHtcxN+gerLs4ltQ4RAp7+AJ4w/32DQsxY/xNKIFtd/iONjO3VbQCaA0hD
vNVR7lsJiTXMnlNkREs7eNQ=
=tHTE
-END PGP SIGNATURE-

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

 http://mail.zope.org/mailman/listinfo/zope )


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

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zc.extrinsicreference release

2008-02-11 Thread David Pratt
Hi. Wondering if zc.extrinsicreference ought to be included in the 
versions.cfg. Currently it is at 0.1dev. It has been this way in the 
repository for about a year. Could/should it be released? Many thanks.


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 3.4.0 candidate 1 Released

2008-02-01 Thread David Pratt
I would say so also. Since z2, z3 both be released in future as eggs, I 
I expect the only difference to be in kgs that ensures a working set of 
packages (whether it is zope3, zope2, or for that matter any other project).


Any sort of release in the future should only reflect a state of a 
working collection of packages. Certainly calling the collection of 
packages that produces a working zope3 installation a library would be 
inappropriate in my view.


One approach might be calling the releases something zope-kgs-2 and 
zope-kgs-3 so it is all branded 'zope' - just refer to the *set* of eggs 
we are taking about. While this is more explicit, it does not sound very 
nice. kgs looks like kilograms to me any time I look at it :-)


It might be nice for the marketing of zope to give each set of eggs a 
nice name. Just using familiar mozilla names as an illustration, see how 
nice zope-thunderbird or zope-firefox look. So do away with the kgs in 
the name and create a brand where zope 2 doesn't look like the lesser 
version of zope and zope3 isn't a library. They are only sets of the 
packages we generally refer to as zope :-)


Regards,
David



Tom Hoffman wrote:


Or if not, it would seem like there would be a better argument for the
new approach having a new name than the old one.

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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope3-Users] Re: [Zope-dev] Zope 3.4.0 candidate 1 Released

2008-02-01 Thread David Pratt
Hi Martijn. I am familiar with grok and the fun and welcoming community 
you have created. With the perspective I have suggested, releases are 
only sets with different names giving meaning to each set for developer 
groups.


As a project, grok is currently pinning eggs but can also provide a kgs 
for the set known as grok. The full story of zope is about the assembly 
of packages into projects. It need not be only one thing or the other 
which is the point. It is really up to individual developers to 
determine their flavor of zope and what it means to their own projects 
and style of development.


My thinking though is that we can create a more cohesive community if 
the code base were all known as 'zope' and developers are all working 
from the superset of zope (which is in essence just the code base of 
packages we all use).


Regards,
David

Martijn Faassen wrote:

Hey,.

On Feb 1, 2008 4:09 PM, David Pratt [EMAIL PROTECTED] wrote:
[snip]

It might be nice for the marketing of zope to give each set of eggs a
nice name. Just using familiar mozilla names as an illustration, see how
nice zope-thunderbird or zope-firefox look. So do away with the kgs in
the name and create a brand where zope 2 doesn't look like the lesser
version of zope and zope3 isn't a library. They are only sets of the
packages we generally refer to as zope :-)


There is this little community project called Grok which among other
things aims at better marketing of Zope 3 technologies:

http://grok.zope.org

We've been at it for over a year. Now with all new website!

I realize that Grok isn't to the tastes of everybody in this
community. They may wish to market non-Grok Zope 3 better. My
suggestion is for them to contribute to the Zope website project:

http://www.openplans.org/projects/zorg-redux

(appears down at the moment, but I think that this is the correct URL)

Regards,

Martijn


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

http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Zope 3 without ZODB

2008-01-15 Thread David Pratt
Hi Chris. I was scanning the lists looking for posts similar to this. 
Were you successful in getting something like this to work? Anyone else 
document anything like this?


I wrote a different main.py at some point about a year or so ago so both 
twisted clients and servers to could be started up using schemas for 
zconfig but am looking at possibilities without and with other non ZODB 
backends. I see Philip provided some clues for a mixin that could be 
used to glue the publisher's traversal mechanism together with an 
alternative storage.  Many thanks.


Regards,
David


Chris Withers wrote:

Hey All,

I'm still continuing poking around (when I have the chance) to see how 
I'd get Zope running without ZODB.


Does the following line:

db = zope.app.appsetup.appsetup.multi_database(options.databases)[0][0]

...from:

http://svn.zope.org/Zope3/trunk/src/zope/app/server/main.py?rev=71011view=markup 



...mean that Zope 3 is currently hard-coded to need a ZODB?

If so, how should we go about making this optional?

(I am willing to put the work in to make this happen if people give me 
some hints...)


cheers,

Chris


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

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zcml entry points

2007-10-18 Thread David Pratt
Hi. I can also see potential uses for this. Hopefully the utility will 
implemented as a zpl package so that it may eventually make it into 
zope.configuration. Many thanks.


Regards,
David

Jim Fulton wrote:

I understand that some folks would fine something like this to be very 
useful.  I can especially see the benefit for pluggable apps, like Plone 
and Zope 2..  I support this idea.  I would almost certainly not use it 
myself and can't justify my time to implement this. I think the 
implementation is pretty straightforward though and encourage folks who 
want this to implement it.  It can be implemented as a separate package, 
although I wouldn't object to eventually incorporating it into 
zope.configuration.


Jim

--
Jim Fulton
Zope Corporation


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


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

http://mail.zope.org/mailman/listinfo/zope )


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

2007-10-07 Thread David Pratt

Andreas Jung wrote:
We don't need to start a discussion about the architecture. 


Apparently we do as since we are talking about zope 3's development 
forum. This is where discussions and decisions for zope 3 occur and I 
don't want this necessarily combined and heavily influenced by zope 2 
development. Zope 2 is a single application that depends on zope 3.

Both
versions have a different history and a different architecture but they 
serve basically the same purpose: building web apps in the first place.


Certainly the same can be said for all other applications with a 
dependency on zope 3. I would not expect these lists to be folded into 
zope3-dev or vice versa. Folks with an interest will simply subscribe to 
the lists they wish to monitor.



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.


I'm not sure where you are going with this but it is disconcerting when 
you start pointing to how many folks are doing this or doing that. 
Because there are more zope 2 developers is also the reason I that folks 
that perpetuate thought and progress on the zope 3 ought to be able to 
do it without the dominating influence of any dependent project. You 
seem to make the assumption that pure zope 3 developers would want or 
welcome this influence. I see this threatening and analogous to inviting 
lobbyists in government to govern the country.


Zope 3 technologies are being used in zope 2 and things being learned 
and they play well together. Ok, that is good. Surely there can be 
dialog with zope 2 development without consuming the communication 
channels and project structures of zope 3.


I think if the tables were turned you could see the point I am making 
more clearly. You wouldn't want someone saying look We are bigger than 
you and we're moving in. By the way were merging our development lists 
we are planning on assuming your identity also. We're now all now just 
zope.


 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.


Yes, subscribing to the list would be appropriate but merging the lists 
is what we are talking about. The arguments you use here give me the 
impression that zope 3 is in jeopardy of being hijacked for use within 
zope 2 and rebranded 'zope'. This is not something I wish to consider 
and would sooner see zope 3 fork than see zope 3 incrementally consumed 
like this.


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

http://mail.zope.org/mailman/listinfo/zope )


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

2007-10-07 Thread David Pratt
Hi Dieter. Zope 2 is one application among many dependent upon zope 3. 
Zope 3 is different software than zope 2. It has a community of pure 
zope 3 developers (that I don't believe the suggestion of folding the 
lists together adequately considers).


Folks have been developing and collaborating on zope2 five and zope 3 
all along with success. More so, I get the impression that the unstated 
goal here is to assimilate zope 3 into a different notion of 'zope' that 
would further obfuscate it as a framework (under the influence of 
zope2). Zope 3 stands on its own as a framework and I sure hope I am 
wrong about how I have been interpreting the dialog.


If the objective is simply working together and staying better informed, 
it does not require a merged list to accomplish this. The objective of 
the zope3-dev list is to serve the development interests of zope3. Folks 
with input or who wish to monitor this should subscribe to the list.


Regards,
David

Dieter Maurer wrote:

David Pratt wrote at 2007-10-7 12:17 -0300:

...
Zope 2 is a single application


Are you sure you know Zope2 ?




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

http://mail.zope.org/mailman/listinfo/zope )


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

2007-10-06 Thread David Pratt
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.


Regards,
David

Roger Ineichen 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.


Another reason for not to switch is the mailinglist observation
in the different web apps out there. They are very usefull.

btw,
a cool app, this is another reason to keep the
trunk up and running. I guess they checkout
our code and count the lines ;-). See:
http://www.ohloh.net/projects/4495?p=Zope+3

e.g.
Codebase 97,598 LOC 
Effort (est.) 25 Person Years

Project Cost $1,348,258

Regards
Roger Ineichen


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
[EMAIL PROTECTED]
Unsub: 
http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch





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

 http://mail.zope.org/mailman/listinfo/zope )


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

http://mail.zope.org/mailman/listinfo/zope )


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

2007-10-06 Thread David Pratt
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.


The fact that zope 3 is not specifically an  application, nor a 
traditional framework is also what can make it difficult for folks to 
distinguish zope 3 as something special. You only understand this once 
you are able to see it for what it is. To the uninitiated it may just 
seem a library of packages (and well, that's missing the point :-)) When 
one looks at the collection of software that makes up the python 
language, they see an elegant way to create. Zope 3 is like this and you 
are free to create anything you wish.


Folks looking for containment within a framework will look for 
traditional solutions that confine their development within a container 
with strict rules and one way to do it all. This has strong points but 
the least of those is flexibility and diversity. Think if our creator 
had thought of only one way to create an animal and the possibilities 
and opportunities lost to create all the diversity we see on our planet.


I've developed in zope2 and recognize and respect it as a powerful web 
platform that answers specific solutions. For me, considerable 
flexibility was lost when you are not programming as a python programmer 
and programming for the api of the application.


I have always wanted what zope 3 provides. I do not want to see it given 
any other ground or see the development of zope 3 pushed or pulled by 
interests that best serve one application or another. Zope 2, Plone 3, 
SchoolTool, Grok, Bebop, and many commercial interests and projects 
including those by Lovely and others are beginning to show how diverse 
Zope 3 can be (and all have an interest in the development of zope 3). I 
should say this diversity extends to desktop applications as well as the 
web.


Personally, I see zope 2 and 3 as distinctly different. The development 
is different and the goals are different. Collaboration is always a good 
idea but in the same way that any programmer depending upon zope 3 
packages will want to maintain an interest in zope 3 development.


I also see zope 2 developers in the same context as other application 
developers that utilize zope3 in their efforts.  Collaboration can occur 
freely without merging the specific development lists or interests of 
grok-dev, zope-dev, plone and other application development (that would 
have simililar interests) in the development list of zope 3.


I don't see zope as a synonym for zope 2 and zope 3 either, any more 
that I could see it as a synonym for SchoolTool and zope3 or Grok and 
zope 3 (though obviously all a part of the zope community with a special 
interest in zope 3). Common ground and unified forums for the community 
is a different interest than merging development lists for the software. 
zope 2 and zope 3 share the same name but it my opinion calling it all 
zope is really a bad idea and perpetuates a problem.


Given the way history has unfolded, i'd have rather seen zope 3 given a 
new name, and have had an opportunity to have dissociated itself from 
zope 2 in a clear way without the premise or goal of trying to fold zope 
2 'the application and zope 3 the framework without a frame together. 
It is alright (and frankly realistic) to suggest we have two software 
lines here that are very different. Personally, I don't see these ever 
being the same and future 'marketing' efforts should respect this if 
marketing is a concern.


The notion of the zope 3 application is fading as it should with the 
developments of the last year. I wouldn't want to see zope 3 revert to 
something or extend parts that have it looking like the zope 2 of four 
years ago for the sake of unifying the developer community under a 
generic zope flag. In any case, long message, but I hope this 
clarifies my view on this.


Regards,
David


Andreas Jung wrote:



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