Re: [Zope-dev] Defining Zope 3.

2009-04-20 Thread Paul Everitt
On 4/20/09 3:35 AM, Martijn Faassen wrote:
 Stephan Richter wrote:
 On Sunday 19 April 2009, Tres Seaver wrote:
 -1.  As a branding choice (as opposed to a technology), Zope 3 *is* a
 dead-end:  it implies a strategy (replacing Zope 2) which we no longer
 believe in.  I think the consequences of the brand confusion are hard
 for those uf us inside to estimate, but they are far from trivial.
 I never communicated to anyone that I believe that Zope 3 is a successor of
 Zope 2. Other people pushed that message.

 That message has been out there from the start, no matter how it arose.
 One way this conclusion was reached was the obvious 3 versus 2. We need
 to fix that situation.

I think Martijn's right on this point.

FWIW, there was a mailing list setup to discuss this when it came up in 
Jan 2003:

 
http://archives.free.net.ph/mindex/zope2-migrat...@20021201.05..en.html

Here's a useful thread showing a dialog between Seb Bacon, Jim, and me:

   http://archives.free.net.ph/message/20030214.073424.f58e0929.en.html

We have arrived at a different result, of course, but it is still useful 
to agree on the background.

We also had the discussion when the decision was made to drop the X in 
Zope 3X, without fulfilling one part of the bullet points for why there 
was an X.

Stephan, I agree that you didn't communicate that message.  But I think 
it is pretty easy to show that Zope communicated that message, 
officially and unofficially.

--Paul

___
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] the Zope Framework project

2009-03-04 Thread Paul Everitt
On 3/4/09 1:07 AM, Chris McDonough wrote:
 Martin Aspeli wrote:
 Chris McDonough wrote:

 Sorry, the you above in you scolded was Martin Aspeli, not Faassen.
 Note that the scolding had something to do with you breaking Plone
 trunk due to a transitive change in Chameleon, and the realisation that
 from this point on, any package shared between repoze.bfg and Plone (or
 anything else) that is configured with ZCML, will probably need to be
 forked. We found a workaround with Chameleon, but not one that will scale.

 The fix is totally scalable and completely correct.  Chameleon.zpt just does 
 not
 have any (real) ZCML anymore.  Any package that has ZCML is, by definition,
 written for some framework as stuff that is meant to be overridden, otherwise 
 it
 wouldn't be written as configuration.  ZCML is unlike code in this way.  If it
 wasn't meant to be overridden, it would be in code.

 All packages which are meant to be maximally useful outside the scope of that
 framework should be split into two things: the library portion, then some
 portion that contains ZCML for gluing in to some framework that wants ZCML in
 some specific configuration.

When I read Martin's post, I had a similar reaction.  Namely, that the 
convenience of the Uberthing (Plone in this case) will always trump the 
desire of packages trying to survive on their own for new audiences.  At 
the time of the configuration scolding, I remember thinking: there's 
little interest here in Chameleon's goal to be bigger than Zope.  Keep 
things convenient for us in Plone!

Package sharing between repoze.bfg and Plone should not mean that BFG 
gets dragged down, paying for things it specifically doesn't want to 
eat.  BFG never claimed to sign up for Plone's contracts.

I sense the logic of Chris's position: if the Zope Framework is as big 
as every current use case in Zope2+Zope3+Grok+etc., with nine years of 
accumulations on each (3 forms systems in one of them), then we're 
missing the goal (IMO).  We'll make life incrementally better for 
ourselves, but we'll still scare off the folks who aren't after Uberthing.

Plone is going towards a smaller-and-smaller core that is only as big 
as the manpower to do a great job at keeping it stable.  Meaning, very 
small.  Hopefully the Zope Framework is a tiny little thing that pays 
only for what it eats.

Hopefully the goal is to make a very good microframework (or even 
better, set of libraries).  If you can't make the best configuration 
language possible because one line of includes to get trusted adapters 
is an unconscionable burden is the rule, then I know how this movie ends.

--Paul

___
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] the Zope Framework project

2009-03-04 Thread Paul Everitt
On 3/4/09 8:16 AM, Martin Aspeli wrote:
 Paul Everitt wrote:

 When I read Martin's post, I had a similar reaction.  Namely, that the
 convenience of the Uberthing (Plone in this case) will always trump the
 desire of packages trying to survive on their own for new audiences.  At
 the time of the configuration scolding, I remember thinking: there's
 little interest here in Chameleon's goal to be bigger than Zope.  Keep
 things convenient for us in Plone!

 In this case, you totally misread my post. It broke for all users of
 zope.component, and I never, once, made the argument that Chameleon was
 part of Plone or should be driven purely by Plone's needs. I have no
 such pretentions, nor does anyone else I know, about this, or zope.* or
 the CMF package or, well, anything that is not expressly part of Plone.

Chameleon provided something that made it work for those users, while 
allowing it to not be burdened by those needs.  Everybody wins. 
Hopefully such solutions will be the norm in the future.

 That particular discussion is over, though, and I have no interest in
 having it again.

These two paragraphs seem contradictory. [wink]  We'll consider the 
matter closed.

--Paul

___
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] the Zope Framework project

2009-03-04 Thread Paul Everitt
On 3/4/09 9:47 AM, Roger Ineichen wrote:
 Hi Paul

 Betreff: Re: [Zope-dev] the Zope Framework project

 On 3/4/09 8:16 AM, Martin Aspeli wrote:

 [...]

 Chameleon provided something that made it work for those
 users, while allowing it to not be burdened by those needs.
 Everybody wins.
 Hopefully such solutions will be the norm in the future.

 That particular discussion is over, though, and I have no
 interest in
 having it again.

 I hope not! I don't like to have any code in an application which
 I don't use.

 But right now I don't see a better solution for the chicken
 and egg problem we have with z3c.pt and chameleon support
 in our base packages. In older days we used monkey patches
 for that problem, but that's no solution anymore.

I agree, and I think this case is a good exemplar for the challenge.

Chameleon wanted to make a good templating engine that was independent 
of megaframeworks.  For that, it needed/wanted a configuration language 
that met your statement I don't like to have any code...I don't use.

But legacy in one of the projects changed this from a self-contained, 1x 
amount of work into a cobweb of bigger issues, control in the hands of 
others, and 10x the work.  Human nature says that's demoralizing.

Hopefully the Zope Framework proposal helps untangle this, and gets to a 
point where you don't have to keep the Uberthing in your head when doing 
something small.

--Paul

___
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] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/2/09 10:13 PM, Martin Aspeli wrote:
 We recognised that there was a problem in trying to make sure we
 represented the interests of various stakeholders, and that we needed
 someone to think big picture in terms of what technologies we adopted
 and how we used them.

Just to be clear, I believe the Plone framework team has specifically 
disavowed management of Plone's strategy.  Meaning, they approve PLIPs 
on a release-to-release basis.  They don't make edicts like replace 
Archetypes.

This was the vacuum that the strategic planning summit advertised 
itself as addressing.

I think this clarification is informative to Martijn's discussion.

--Paul

___
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] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/2/09 6:36 PM, Martijn Faassen wrote:
 Hi there,

 To people who are suggesting we don't need a steering group nor a name
 for the Zope Framework, please answer the following questions:

 * how will the community make hard decisions where lots of people
 disagree? What is the mechanism for making hard decisions? Don't say Jim
 makes them because as you may have noticed Jim *hasn't* been making so
 many of those in recent times. We need to solve this problem.

Ultimately I think I agree with Chris's position.  I think the days are 
past when we could commit to the success of an overarching Uberthing, be 
it a macroframework, platform, or app server.  Rather than commit your 
reserves in a desperate attempt to win the battle, you withdraw to avoid 
losing your whole army.

That notwithstanding, if Zope is still the goal, I endorse Martijn's 
proposal.  Like Gary said, it's admirable that he's taking a shot at 
this and we should bite our tongues on quibbling.

In the past we've seen things like let's unify Zope by merging the 
Zope2 and Zope3 mailing lists get shot down by a couple of loud no 
votes.  Loud no's have grown paralyzing.  If Martijn's proposal gets 
traction, then perhaps we have a way around them.

--Paul


___
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] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/3/09 9:37 AM, Kent Tenney wrote:
 I'll chime in as a newbie.

 It seems many of the comments preferring ad-hoc to structure
 come from we know what we are doing, we can take care of ourselves

 I think Zope has the goal of attracting new users, and the proposal
 has potential to make Zope more inviting to the uninitiated.

 Zope is very diffuse, making it a challenge to grasp. I know I would benefit
 from any initiative which sought to provide an overview role.

I'm not sure that's a goal of this proposal.  The word Zope will 
continue to have its previous series of semi-competing meanings.  The 
word will now also be attached to Framework, which will be the emphasis.

As I read it, regarding the diffusion, asking the stakeholders in the 
existing meanings of the word to yield is not part of the proposal. 
(Thankfully, as that is hopeless.)

The focus, though, will be on greatest-common-factor of the shared 
meaning.  Not a solution to diffusion, but an improvement.

--Paul

___
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] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/3/09 2:42 PM, Chris McDonough wrote:
 Martijn Faassen wrote:
 And you think it's all due to the brand...

 Yes!  Someone who *wants* to use basic ZCML directives but doesn't want
 zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and
 pytz can *already* use repoze.zcml; the only thing they don't get here is the 
 brand.

If we change the word brand to megaframework, things might become 
clearer.

Grok makes framework decisions based on getting value from the Zope 3 
platform. So what if our configuration language sucks in zope.location 
and pytz, we needed it anyway in our megaframework!  This view likely 
represents the (indeterminately sized) population of Zope insiders.

Repoze doesn't have fidelity to the Zope 3 megaframework as its goal. 
I asked for a configuration parser and you sucked in a security model, 
WTF!!  As such, Repoze probably wants something more like 
Zope-the-library than Zope-the-megaframework.  This view likely 
represents the (indeterminately sized) population of Zope skeptics.

Which group wins when there's a tie in the Zope Framework?  It will be 
interesting to see.

I think there's also a point about the brand related to how diluted 
the word Zope has become, but that is a second point to the 
megaframework/platform discussion.

--Paul

___
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] Re: sad news about Joachim Schmitz

2008-05-15 Thread Paul Everitt

Martijn Faassen wrote:

Hi there,

Joachim Schmitz, long-standing member of the Zope community, died last
weekend. Please see the following:

http://faassen.n--tree.net/blog/view/weblog/2008/05/14/0


That was a wonderfully written memoriam, Martijn, thanks for writing it. 
 A number of things you wrote brought back very vivid memories of 
Joachim.  He's one of the originals and we were lucky to have him as 
part of our community.


--Paul

___
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] Two visions?

2006-03-02 Thread Paul Everitt

Stefane Fermigier wrote:

Geoff Davis wrote:

I think that the idea of giving Zed its own, distinct identity is great..


I think it is stupid.

We (Zope Corp + the Zope Community) have spent 8 years building the Zope
brand, and you want to restart from scratch ?


Hehe, poor Geoff. :)

In the past, the Zope community hasn't made it a *strategic* goal to 
play nice with other Python projects.  In the past, the Zope community 
hasn't made it a goal to be a sea of autonomous components.  Its goal 
has been: top-to-bottom app server.


We now have (I think!) said those goals are now in scope.  Those goals 
are currently being met using the same name as the assembly.  Trying to 
achieve the goals of the components, using the same word as the 
assembly, might not be the best way to achieve those goals.


The comments I got on my pro-Zope weblog post showed that, if we *do* 
care about these new goals, we should consider whether the name is a 
barrier *for the components*.


Alternatively, we could say: The components should only be used in the 
Zope application server.  Perhaps that's the goal.


I think Geoff's core point could be met by keeping the word Zope for 
the app server.  I think Geoff's deeper point was to rethink the word 
used for the CA, which actually doesn't want to be thought of us an app 
server.


--Paul

___
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] Two visions?

2006-03-02 Thread Paul Everitt

Geoff Davis wrote:

On Thu, 02 Mar 2006 10:38:03 -0500, Jim Fulton wrote:

I think that the idea of giving Zed its own, distinct identity is great. 
Zope 3 is a _huge_ overhaul and it needs to be obvious to the world that

it is dramatically better than crufty old Zope 2.  Zope 3 then becomes the
Zed application server; Zope 2 is getting Zed retrofits via Five, and the
two will eventually converge into Zope 5 (or Zope 2.27 or whatever).

Ooops.  OK I guess I was clear as mud. :)  My idea for Z, pronounced zed
or whatever the naming gods decide is that it was *not* an app server.
It is an un-app-server. :)  A collection of technologies that are useful
by themselves, to support an app server and useful to build non-app-server
applications, web or otherwise.


No, I think I understood you.  I was being sloppy in my use of language. 
I should have said something more like Zope 3 then becomes an application

server built around the Zed library.


Good clarification.


I think that Z3 is better than Z2 in a lot of ways.  I also think that
Z2 is more mature and complete.  I really want us to combine those efforts.
I think we've achieved enough and learned enough with Zope 3 that we
can now bring that to bear and make Zope 2 better, refactoring the cruft
away and applying the lessons we've learned with Zope 3.  (Note that Zope 3
is not crust free.)  I don't really care what this thing ends up being called,
except that it *must* be called Zope.


Yes, I agree.  Zope is the app server.  I think that is consistent with
the past use of the brand.


Yep.


This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's
advice and release our technology in bite-sized chunks.  I'm hopeful that the
packaging efforts underway will lead to more of that.


Yes, and the use of the new name Z or Zed is a way to emphasize that
the Zed library is NOT a big, monolithic app server; rather, it's
something new and cool.


I think this brings up an interesting paradox in the discussion.  We 
want Zope to continue being the name of an app server.  But we also want 
the CA to be perceived as usable outside of an app server.  Outside of 
Zope, even.


Thus, we are using the same name used to convey:

  It *is* an app server!
  It's *not* an app server!

I think this might be a contradiction and might be worth discussing.

People have it set in their brain that Zope is a monolithic web 
application server.  Hard to dispel that meme.


--Paul


___
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] Re: [Z3lab] Nuxeo supports Zope Corp announces

2005-06-17 Thread Paul Everitt


On Jun 17, 2005, at 1:49 PM, Jean-Marc Orliaguet wrote:

However, most members do not write code during their free time, do  
they?

What happens when the members write code under working hours, their
respective employers must well have something to say about it?



The PF actually did research on this and got legal help from Eben  
Moglen and the Software Freedom Law Center.  Answer is: almost the  
same way as Apache does it and the FSF does it.  The employer signs a  
contribution agreement *but* is not a voting member of the foundation.


--Paul


___
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] Re: [Z3lab] Nuxeo supports Zope Corp announces

2005-06-17 Thread Paul Everitt


On Jun 17, 2005, at 1:52 PM, Stephan Richter wrote:


On Friday 17 June 2005 07:16, Jean-Marc Orliaguet wrote:


Then when I look at the members of the Plone foundation (
http://plone.org/foundation/about/board/list ) I only see companies,
except that ZC is not represented. So even if every member gets a  
vote,
how much does that vote count in the development process of Zope2,  
CMF

and Zope3 ?



Ugh, I hope I misread this. If the foundation or any other  
instituation ever
influences the Zope 3 development process, I will not contribute  
any more. I
rather have ZC-centric development platform and the freedom to  
choose what to
do for a release (in agreement with the other Z3-core developers)  
than a
vender-independent foundation with a foundation-driven development  
cycle.


In the case of the Plone Foundation, the PF is specifically excluded  
from the development process of the community.  Its mandate is  
limited to organizational issues.


Other foundations approach things a bit differently.  (I did quite a  
bit of research on this for the Plone Foundation.)


Also, I agree with Andreas and Philipp that developers should be  
members, not
companies. Otherwise, how could I, as an independent developer,  
have a say?

BTW, this is also positive for companies, since they can have several
developers being members. In the proposed scenario, my one-man shop  
would
have a lot of power compared to larger companies, such as ZC,  
Nuxeo, etc.


Correct.  The essential ingredient, and hardest one for the different  
cultures of different communities, is to establish the definition of  
merit.  Is it only code?  If so, how much and what kind?  If not,  
what else is valuable?


Most of the successful communities have a (subjective) definition of  
merit, used to evaluate membership.


--Paul

___
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] Re: [Z3lab] Nuxeo supports Zope Corp announces

2005-06-17 Thread Paul Everitt


On Jun 17, 2005, at 2:49 PM, Stefane Fermigier wrote:


Paul Everitt wrote:

Other foundations approach things a bit differently.  (I did quite  
a  bit of research on this for the Plone Foundation.)




Eric has done some research recently on the different successful  
Open Source / Free Software foundations out there that have the  
mission to develop and promote great software.


We're looking for a model that is just as acceptable for the single  
developers (who are a very key elements in the community, and  
provide some of the best work around - see Stefan or Philip for  
instance, but there are many others whitout whom Zope and specially  
Zope3 would not exist as we know them today) but also for the  
companies and organisations that depend on Zope for their business  
and are willing to commit ressources to the development of the  
software (this includes software development houses like Zope Corp,  
Infrae, Nuxeo and 10s of others, but also companies or universities  
or non-profit that depend on Zope for their ongoing operation -  
like Chalmers university or like the SD houses customers).


:^)

IMHO, vendor-neutral means, in this context, that the Foundation  
must take into account the interests of all the stakeholders  
(individual hackers, vendors, customers), and shouldn't be  
interpreted as vendor-free.


The governance model should take that into account, and not limit  
itself to only individuals are members (of course, companies are  
represented by individuals, but what happens if the individual in  
question leaves a member company for another?).


First, let's agree that this isn't pre-decided.  That the community  
will get the governance model it wants.  Agree?


Second, can you find examples that support this?  For example, here's  
what Apache says:


http://apache.org/foundation/how-it-works.html#roles

All of the ASF including the board, the other officers, the  
committers, and the members, are participating as individuals. That  
is one strength of the ASF, affiliations do not cloud the personal  
contributions.



Here's what GNOME Foundation says:
http://foundation.gnome.org/membership/

Membership eligibility is an individual determination: while  
contributions made in the course of employment will be considered,  
they will generally be ascribed to the individuals involved, rather  
than accruing to all employees of a contributing corporation.



These are two very successful open source projects.  However, there  
is nothing to suggest that our culture is the same as these others.   
What's most important is that the rules are defined by the  
community.  Let's ensure that the bootstrapping group is representative.


--Paul
___
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] Re: [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements

2005-05-14 Thread Paul Everitt
This is really interesting!  A year ago I put Python + Zope on a USB 
key, just for fun.  It would barely fit so I looked at zip techniques, 
and never could figure out how to get ZPTs etc. to load from a ZIP.

How did you do that part?
--Paul
Dieter Maurer wrote:
Dear Zope developers,
we have used Zope+CMF+Archetypes in a new way -- not
as a Web Application framework but as a framework for
desktop applications that share a large part of their
functionality with online applications (implemented with Zope+CMF+Archetypes).
A major stumbling block has been Zope's incredibly high startup
time. We observerd times in the order of a minute on computers
with either slow CPU or slow IO. This may be acceptable for
a Web server but is prohibitive for a desktop application -- especially
as the predecessor application started within a few seconds.
To overcome this obstacle, we tweaked Zope and fixed Python's import
mechanism such that Zope now starts either out of a ZIP archive
or as a frozen application. These measures had the following results.
  Startup times on a mid range computer (AMD Athon 1.4 GHz; 512 MB memory)
  with a standard IDE disk.
Cold start  Warm start
(after computer startup)(most files in OS cache)
File system13s5s
ZIP archive 8s4s
Frozen  5s3s
In more details, we did:
  *  implement a package for a new kind of urls pypackage:
 for package relative access to resources.
 The package monkey patches Python's open, os.listdir,
 os.stat to provide transparent access to
 pypackage: identified resources.
 It currently support package relative access for
 packages loaded from the file system, from a ZIP
 archive and from the executable itself (i.e. frozen packages).
 In the last case, the resources are in a separate ZIP
 archive.
 This package might be interesting for Python as a whole
 as it is not Zope specific.
  *  implement a shared object importer to be used
 as a Python meta_path hook.
 This importer allows to load shared objects into the context
 of a parent package (such as e.g. ZODB.TimeStamp) although
 the shared object is not located inside the package's source
 (ZIP archive or executable).
  *  fix about 70 occurrences in Zope code where
 package relative access was implemented by dirname(__file__)
 to consistenty use package_home.
  *  modify about a dozen places in Zope+CMF to use
 pypackage: and cope with __path__ not being a list
 for frozen packages
  *  fix a few products (Archetypes and friends, TextIndexNG2,
 PlacelessTranslationService, ...) to use
 package_home (rather than dirname(__file__)) and
 not to change the current working directory (which obviously
 would fail for destinationsbe in a ZIP archive
 or the executable).
  *  implement lazy loading of ImageFiles to
 reduce the risk of recursive imports (and reduce startup time).
  *  support lazy product initialization
  *  support configuration from a pickle file (to avoid
 expensive parsing of the schema and configuration files).
 The pickle is used as a configuration cache.
  *  fixed Python's import mechanism not to treat ZIP
 archives as a directory when the archive could not
 find a module.
If you were *really* interested in these startup time improvements,
I could provide patches which might be integrated
in the Zope core for e.g. Zope 2.9.

___
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] Re: Editing using Firefox

2005-04-16 Thread Paul Everitt
Are you doing this as a XUL app, with an html/xul iframe inside each tab?
--Paul
Jeff Nielsen wrote:
Sorry in advance if this issue has been covered a bzillion times already
 

Im playing with editing my Zope site using Firefox as I can open 
Document and Method objects in tabbed windows and switch back and forth 
between them. However, the tab title, based on the page title, for each 
object is just Zope. Is there a way to get the object name to be used 
as the page title and hence the tab title? Ive searched about a bit for 
an answer and no joy so far.

 

Jeff Nielsen
UgoFast
http://www.UgoFast.com
[EMAIL PROTECTED]
 


___
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] Re: Zope3, CMS, IDEs (was: The bleak Future of Zope?)

2004-04-22 Thread Paul Everitt
On Thu, 22 Apr 2004 11:15:58 +0100, Seb Bacon [EMAIL PROTECTED] wrote:

Joachim Werner wrote:
There are quite a few Zope-based CMS solutions out there, and most of  
them are better than their commercial counterparts in many respects.  
But if we had managed to start a joint CMS effort (other than CMF,  
which is a failure by design) two or three years ago things would look  
even better now.
It would be great to start something like a Zope3 CMS interest group up,  
to pool all our CMS experience - start collecting requirements, etc.  
Seems like a mighty large task, though :-)

I'd like to at least have a session on this topic at Europython.
Heimo and I have proposed a panel with the CMS's for Zope, to discuss the  
future of content management in Zope.  My goal is to have a session that  
is structured enough to actually make a constructive step forward, if only  
in understanding and agreement.  Particularly regarding Zope3.

The panelists would be the implementors of current CMSs for Zope.  How  
bout you, Silva, CPS, and Plone?  Any others?

--Paul



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


[Zope-dev] Re: RDF Musings and TinyTables

2003-02-20 Thread Paul Everitt

Good grief, how did I miss this!!

Shane Hathaway wrote:

I just read the RDF article published here:

http://www.xml.com/pub/a/2003/02/12/rdflib.html


Yes indeed, that is a very good article.


I've understood the mechanics of RDF for a while, but never understood 
what makes it better than what we already have.  Now I think I get it: 
RDF theory is a new kind of database abstraction.  It's similar to a 
relational database in that you put pieces of data into the database and 
later search for data.  But it's much more ad-hoc than a relational 
database.

I think you are 100% correct, maybe 110%. :^)

In the last two years I made several attempts at grokking Mozilla and 
RDF was always the wall I ran into that prevented further progress.  In 
the last three months I slowly, surely, forced myself to study it. 
Write things down, take notes, rewrite them down, etc.

The light bulb has definitely gone off for me now, and I see things 
exactly the way you describe it:

1) It's an abstraction.  Once you start working with it, you realize 
what this means.  You take a bunch of information and throw it into a 
bucket.  You also throw in how the information relates to each other.

2) It's a database.  You have a pretty formal way of asking questions 
and making sense of the stuff in the bucket.  You also have a way to put 
things in the bucket, and also to rearrange the stuff in the bucket.

3) It's ad-hoc.  You don't have to know everything beforehand like SQL. 
 You also don't have to control the containment hierarchy like you do 
with XML.  (Took me a LONG time to realize the significance of the 
latter point.)

The ad-hoc part is, for me, the key.  Relational theory provided the 
theoretical foundation for modern online transaction processing.  But 
things like content management are a much different problem.  (One 
analyst states that unstructured content is 80% of the information in a 
business.)

RDF, in my view, is the equivalent of a set theory, a formal 
foundation, for content management.  Without it, everyone has to build 
their own framework for stitching things together, for connecting the 
dots.

Serialization of RDF into XML and the relationship between RDF and the 
Semantic Web are distinct concepts from RDF theory.

That's right.  I've always been surprised when I threw some RDF/XML into 
Mozilla, then got a dump of the serialized results.  What I put in 
doesn't look like what I get out.  That's because there is an abstract 
model.  The XML can look a couple of different ways, and you still have 
the same abstract model.

It took me a while, but I learned how to take advantage of this.  With 
Moztop, I'm taking a pretty loose, distributed approach to content 
managment.  I collect RDF from a bunch of different servers, throw it 
all into one big graph, and use this to draw widgets on the screen.

The ability to make an assertion into a completely different part of the 
tree is something you can't do in XML.

This ad-hoc data storage made me think of TinyTables.  TinyTables is a 
good Zope product that fills the need for simple tables of data, but it 
needs attention.  What if it got replaced by some Zope product called 

I will do everything in the universe to help such a project.  How is 
that? :^)

I know what the practical benefits that RDF can mean for content 
management.  And it isn't esoteric Semantic Gibberish.  I'm unable, 
though, to map it on the server side.  However, I'm having luck on the 
client side:

  http://www.zope-europe.org/Members/paul/tmp/moztop-pinstripe.png

RDFBucket?  An RDFBucket object would let you input data in a variety 
of ways, including object introspection, forms, and XML with embedded 

Yes, this is very similar to the client side model in Mozilla.  I'm 
doing things like:

  o Assembling a hierarchy

  o Making up new hierarchies where none existed before

  o Generating property sheets

  o Doing conditional display

  o Making rich connections between loosely-coupled objects, meaning,
  objects that didn't expect to be coupled

  o Allowing data from Zope 2 and Zope 3 sites to be
  collected, presented, and related in the same interface

Mozilla's template model is interesting to at least investigate.  What's 
interesting about it is the way you can follow relationships in the 
model to draw things on the screen:

  http://www.mozilla.org/docs/xul/xulnotes/template-primer.html

In this very simple example:

  http://www.mozilla.org/docs/xul/xulnotes/template-bindings.html

...note the last two resources shown in friends.rdf.  Instead of 
repeating information in every row, you get the equivalent of a join. 
 Except the result of that join can produce another join.  The template 
builder keeps following relationships.  Also, you can join to something 
on another server.

RDF.  It would let you run queries similar to ZCatalog.  Maybe it would 
also generate RDF for embedding metadata in web pages

I'm wondering if I'm thinking in line with RDF theory, 

Re: [Zope-dev] Re: RDF Musings and TinyTables

2003-02-20 Thread Paul Everitt

On Friday, Feb 21, 2003, at 04:16 Europe/Paris, Craeg K Strong wrote:


Paul Everitt wrote:


On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote:


- RDF is hard to read, but legibility by humans isn't its primary 
focus.  It's more concerned with providing a way to declare any 
relationship about anything.


Right.  That's what the graph tool at the W3C online validator is 
for. :^)  Just throw it some RDF and let it draw a picture for you.

Fascinating discussion.  Could you please share the URL of this 
validator you mentioned?

http://www.w3.org/RDF/Validator/


I am assuming it is based on GraphViz/IsaViz technology?  Or is it 
something totally new?

Nope, it is indeed GraphVis underneath.

--Paul

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



Re: [Zope-dev] Plone/Metadata/FUD

2002-10-03 Thread Paul Everitt


On Thursday, Oct 3, 2002, at 03:54 Europe/Paris, James Johnson wrote:

 I've been around the Zope/Python scene for many years.  One thing I 
 see this group suffer I believe if from the groupthink mentality.  
 Imho Alexander Limi 2 cents worth demonstrated Erik's point 
 perfectly.   applaud the effort made with plone.  I believe it to be a 
 spoon in which we can spoon feed newbies into the CMS side of the Zope 
 way.
  Seem my post regarding Zopezen.org.  Plone is slow.  Zope with CMF is 
 slow... Not as slow as plone, but the issue is with ZPT.  There is no 
 way around it Erik is right.  Developer time being spent on speeding 
 up plone in order to backport the improvements to Zope/CMF sounds... 
 Well arse backwards.  Plone has its place, but I suspect some 
 doublespeak here, lets be realistic about it.

The Plone people are a layer above CMF, which is a layer above Zope, 
which is a layer above Python, which is a layer above the C library, 
which is...

Do the Plone people have responsibility for all the layers below them?  
Nope.  If there was a bug in the Python compiler (and in the last six 
months, there was one), should Plone have to fix it?  Should they also 
fix problems in the Linux virtual memory model if they find that too?  
Nope.

   I debated a long time ago about CMS being the core of Zope anyway, 
 but lo and behold they pushed on with a CMF product.  I see plone as 
 being the same, a

Two errors here:

a. The Zope community, on the whole, doesn't want Zope narrowed 
exclusively to content management.

b. The CMF isn't a product.  It is a framework.  It specifically 
intends to not be a product.

  product. Now my understanding is that with Zope3, they will roll a 
 lot of the CMF functionality into Zope3 Hmm go figure?  All that 
 time wasted on maintaining 2

This isn't precise.  The CMF machinery, the part not unique to content 
management, is going into Zope 3.  The effort for content management in 
Zope 3 is being managed as a companion project:

   http://lists.zope.org/pipermail/zope3-dev/2002-September/002819.html

I'll note that you are neither subscribed to the Zope 3 mailing list, 
nor have you commented on the email above.  If you're not even 
participating, then you should be more circumspect when making 
assertions such as:

  products Zope/CMF has proven cumbersome at the least imho.  Now just 
 imagine if the community would have listened to the lone voice 
 James-then/Erik-now where we

...this.  How can we listen to you if you're not participating?  But to 
your point: the Zope community does not want, IMO, Zope and CMF merged. 
  Content management is a piece of the Zope pie, not the whole pie.

  would be today.  We all know that the decision back then was based on 
 commercial interest for ZC and others trying to market some industry 
 catch phrase.

I have no idea what you are claiming.  In fact, the reverse is true: ZC 
is focused on content management, but ZC realized others want to do 
different things with Zope.  Thus ZC didn't turn Zope into a 
CMS-exclusive thing.  Doing the CMF outside of Zope allowed the CMF to 
make rapid progress in a focused area without making promises that Zope 
itself would have to live with permanently.

This has worked perfectly.  We all now know a lot more about the 
patterns of content management.  We can now refine them, and refine 
Zope, with the work on Zope 3.

Tell me, do you think KDE should be merged into X11?  It is exactly the 
same analogy.

You're also claiming that Erik is voicing your opinion.  I don't 
believe Erik wants a one-size-fits-all CMS product that everyone must 
support, nor do I believe Erik wants Zope to be focused exclusively on 
content management.  However, I don't pretend to speak for Erik, so he 
can correct me if I'm wrong.

   So I hear you Erik, you have these wonderful, bright people working 
 on special interest projects, but not on the core issues that allow 
 Zope to have that strong core that it needs to move it forward.

People work on what they want to work on.  Alex Limi knows CSS and 
doesn't want to learn how the ZPT compiler should be optimized in C.  
It is unfair that you demand that he learn how to program in C.

It is also wrong.  Zope has more people that know C than know CSS well. 
  We are lucky that Alex is filling an unmet need in the world of Zope.

  With it being evident in how the Release early/Release often mantra 
 has been

Explain how this is thrown by the wayside.  You can, every single day, 
make a checkout of any part of Zope.  Sure there was a gap between 2.6 
alpha and 2.6 beta.  But that's a single datapoint.  Name another 
datapoint to support your conclusion.

  thrown to the wayside, I'm left wondering what do I do next with my 
 2.5.1 site?  Do I go the plone, 2.6, 2.7 or 3.0 route?

Going the Plone route is orthogonal to choosing a Zope version.

Not a single person in the world of Zope claims that 3.0 could even run 
a prototype system, much less 

Re: [Zope-dev] Zopezen.org is slower! Should time be spent on Plone or ZPT speed?

2002-10-03 Thread Paul Everitt


On Thursday, Oct 3, 2002, at 07:14 Europe/Paris, Andy McKay wrote:

I smell commecial interest here.  I smell people trying to make 
 that
 one
 killer project hoping to make it big, instead of centering around the 
 one
 vehicle that will help make a bunch of projects big someday.

 I won't deny it. I believe I can sell Plone and I'm not sure I can 
 sell Zope
 as easily. Its a simple fact that I have to sell what the clients 
 want: if I
 spend all my time concetrating on Zope innards, I doubt I'll be able 
 to pay
 the mortgage. In the last 3 months 75% of my clients have come to me 
 for
 Plone, in one case I steered them to a solution in Zope because I felt 
 it
 was a more appropriate solution.

I agree with Andy.  Zope is a tool.  Things like Silva and Plone are 
products.  The purpose of Zope is to allow people to build things like 
Silva or Plone, or things quite different (perhaps custom to their own 
needs) quickly.

And frankly, tools don't sell themselves.  People want to see glitz.

You could argue that Zope should be the project/brand with the glitz.  
But you're now limiting people's choices, because you're turning Zope 
into a product rather than a tool.

Back to the X11/KDE argument.  Ever looked at an X11 server running 
w/out a window manager?  That's Zope.  But it's wrong to fix the 
problem by eliminating X11 and merging it with KDE, because then the 
Gnome (and windowmaker, and sawfish, and...) people would be unhappy.

Layers provide choice.  Sure, they also provide a bit of confusion, but 
this cost is far outweighed by the benefits.  Especially in open 
source, where people participate because they want to participate, not 
because they have no other choice.

--Paul


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



Re: [Zope-dev] Zopezen.org is slower! Should time be spent on Plone or ZPT speed?

2002-10-03 Thread Paul Everitt


On Thursday, Oct 3, 2002, at 10:51 Europe/Paris, James Johnson wrote:

  Please don't get me wrong, products like squishdot, CMFZen, and 
 others have steered me towards Zope.  They are fine examples of the 
 things that make Zope appealing.  But if you really think about what 
 I'm saying you might understand my meaning.  Zope--is to MTV and 
 Plone -- is to VH1.  Squishdot-- is to CMT.

The funny part of your analogy: MTV is the creator and owner of VH1.  
Now why do you suppose they did that? :^)

--Paul


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



[Zope-dev] Interested in sprinting at EuroPython 2002?

2002-05-30 Thread Paul Everitt


First, as a friendly reminder for EuroPython 2002:

 ***Early registration is open !!!***
 ***   https://secure.zope.nl/europython/Registration ***

Deadline is May 31. Now, on to the good stuff.

The EuroPython 2002 conference, http://www.europython.org, is in
Charleroi, Belgium. We are planning a sprint the Sunday, Monday,
and Tuesday before the confernce, making this sprint cover
June 23-25.

The goal of this sprint is like most others: education and spreading
the word. However, we would like this sprint to attract a group of
people that are committed to participating in Zope 3 after the sprint.
If your interest is simply in learning about Zope 3, there is a tutorial
the first day of the conference that might be more appropriate.

The requirements are simple: you need to know how to develop in
Python. Even Zope experience isn't mandatory (though it is quite
useful.)

We hope to have two groups of sprinters, with 6 or 8 people in each
group. This means 3 or 4 pairs.

If you are interested in sprinting and want to participate in the
ongoing development of Zope 3, please email me (Paul Everitt,
[EMAIL PROTECTED]) to sign up.

More (and updated information) is available at:
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/EuroPython2002Sprint

--Paul




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



Re: [Zope-dev] how bad are per-request-write-transactions

2002-04-19 Thread Paul Everitt


ForkedStorage, I like it simply for the coolness of the name. :^)

But it sparked a different kind of idea, leveraging a pattern that might 
emerge in Zope 3.

Let's say we had a queue in Zope.  We could asynchronously send changes 
into the queue.  Later, based on some policy (e.g. idle time, clock 
ticks, etc.), those changes would be enacted/committed.

Imagine the queue itself is in a different storage, likely 
non-versioned.  Imagine that the queue is processed every N seconds.  It 
takes all the work to do and performs it, but in a subtransaction.

Thus you might send the queue ten increments to a counter, but only one 
will be committed to the main storage.

To make programmers have to think less about the queue (send in the 
object reference, the method to use, and the parameters), you could make 
it look like a special form of subtransactions.  That is, you say:

   tm.beginQueuingTransactions()
   self.incrementCounter()
   self.title='Simple change'
   self.body = upload_file
   tm.endQueueingTransactions()

At the transaction level, all enclosed changes are queued for later 
commit.  You don't have to think any differently than rather object 
state management.

This pattern applies better when you have a lot of document cataloging 
to be done.  A separate process can wake up, make a ZEO connection, and 
process the queue.  I don't think that indexing documents *has* to be a 
transactional part of every document save.

Under this cron-style approach, you also pay less of a conflict-error 
penalty, as you can increase the backoff period.  There's no web browser 
on the other end, impatiently waiting for their flaming logo. :^)

Ahh well, fun to talk about.  Maybe this time next year we can repeat 
the conversation. :^)

--Paul

Shane Hathaway wrote:
 Jeremy Hylton wrote:
 
 CM == Chris McDonough [EMAIL PROTECTED] writes:



Completely agreed.  My disagreement is portraying the counter
problem as impossible with the zodb.  I think some people, as
evidenced by some of the responses, are willing to live with the
tradeoffs.  Other people will find managing a log file on disk to
be a more manageable solution.

   CM It would be best to make make a dual-mode undoing and nonundoing
   CM storage on a per-object basis.

 I'd really like to do this for ZODB4, but it seems hard to get it into
 FileStorage, without adding automatic incremental packing to
 FileStorage.

 Example: Object A is marked as save enough revisions to do a single
 undo.  When a transaction updates A and makes older revisions
 unnecessary, there's no obvious way to remove them without doing a
 pack.  We could write a garbage collector that removed unneeded things
 (as opposed to packing everything to a particular date), but it
 doesn't seem very useful if it needs to be run manually.
 
 
 One idea I've been floating in my head is the idea of a forked 
 storage, where some objects are stored in an undoable storage and others 
 are stored in a non-undoable storage.  I could try to explain it in 
 English but pseudocode is easier:
 
 
 class ForkedStorage:
 
 def __init__(self, undoable_storage, non_undoable_storage):
 self.undoable = undoable_storage
 self.non_undoable = non_undoable_storage
 
 def store(self, oid, data, serial):
 if not serial or serial == '\0' * 8:
 # For new objects, choose a storage.
 want_undo = self.wantUndoableStorage(data)
 if want_undo:
 storage = self.undoable
 else:
 storage = self.non_undoable
 else:
 # For existing objects, use the storage chosen previously.
 if self.undoable.load(oid):
 storage = self.undoable
 else:
 storage = self.non_undoable
 storage.store(oid, data, serial)
 
 def load(self, oid):
 data, serial = self.undoable.load(oid)
 if not data:
 data, serial = self.non_undoable.load(oid)
 if not data:
 raise POSException, 'data not found'
 return data, serial
 
 def wantUndoableStorage(self, data):
 u = cpickle.Unpickler()
 module, name = u.loads(data)
 class_ = getattr(__import__(module), name)
 if getattr(class_, '_p_undoable', 1):
 return 1
 else:
 return 0
 
 
 Only a simple idea. :-)
 
 Also, how would you specifiy the object's packing policy?  I'm
 thinking an _p_revision_control attribute or something like that.  If
 the attribute exists on an object, it sets a particular policy for
 that object.  
 
Do individual transactions need to play in this game, too?  I'm
 
 imagining a use case where an object is marked as no revisions but
 you want to be able to undo a particular transaction.  I'm not sure if
 that means :

 - you can undo the transaction, but the no revisions object
   keeps its current state.

 - you can undo the 

Re: [Zope-dev] Re: [Zope3-dev] Are there Graphic Designers?

2002-04-05 Thread Paul Everitt


I think this conversation is trending in the wrong direction.

Zope 3 needs to make it possible to build YABB, interfaces which support 
all browsers while still looking slick, etc.

However, it is important to note: Zope 3 is *not* a product.  It is used 
to build products.  The core ZMI is needed to the extent that it helps 
build or administer products.  Thus, Zope 3 is not like YABB.

Of course, Zope 3 can ship with one or more sexy sample applications, 
like YABB.  But if we blur the line for Zope 3's ZMI, we'll be right 
back into the core problem of Zope 2's ZMI: audience confusion.

One of the first questions to ask when building an interface is What is 
the audience?  Giving a very focused, tough response can greatly boost 
effectiveness.

With all this in mind, I think we can require developers to use 
standards-compliant browsers, and allow/facilitate them to build 
backwards-compatible interfaces.

--Paul

William Trenker wrote:
 At 12:47 AM 4/5/02 -0500, you wrote:
 
 I've spent more time making the Python docs work in NS4 than making 
 them look good in more modern browsers
 
 
 This is sad but true.  I still have Netscape 4 here for testing as 
 well.  (I run into the same problem with other web technologies, like 
 Macromedia Flash.  Yes, probably 97% of browsers do have a Flash player 
 installed, but what version?  Many are still at Version 3.)  Those 
 Download FREE upgrade buttons may as well be invisible.
 
 I don't think we should let Zope3 look ugly on old browsers, but isn't 
 it acceptable for it to look more modest?  With careful use of CSS, it 
 is possible to let the older browsers fail gracefully.
 
 And it is amazing what can be done with very little CSS and lots of 
 images.  The page at, http://www.yabb.info/community/, has 2 styles, no 
 Javascript, and looks very respectable.  But look at all the GIF's.
 
 If the web-centric, software-tools development community feels strongly 
 about perpetuating old browsers (and old web standards) then isn't it 
 about time for that community to provide tools to hide the details?  
 When will Python, and for sure Zope, have built-in browser detection and 
 formatting support driven by some sort of meta format that let's us 
 application developers get on with developing applications?



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



Re: [Zope-dev] Bug days

2002-03-15 Thread Paul Everitt


I don't think we can do the geographic coverage without making it too 
painful.  We should split bug days in half; a few hours in the morning 
and a few hours in the afternoon.

--Paul

Brian Lloyd wrote:
 Hi all - 
 
 In an effort to better keep up with the collector, I'd like
 to throw out the idea of doing periodic bug days (a la 
 the mozilla bug days), where Zope geeks and committers would 
 get together on IRC and spend a few hours knocking out issues.
 
 I've drafted a preliminary bug day manifesto that describes 
 how it would work in a little more detail:
 
   http://dev.zope.org/CVS/BugDays
 
 I'd like to hear what people think, as well as work out a few 
 logistics:
 
   - Given the wide geographic area that committers (and patch 
 submitters) cover, what is a good time of day for a bug 
 day to start / end (where start and end are always going 
 to be fuzzy, of course).
 
   - Would it be better for bugdays to be ad-hoc, or should we 
 try to set up regularly-scheduled bugdays at some reasonable 
 interval? If the latter, we need to come up with a day / time 
 that is agreeable to as many of the committers as possible.
 
 Thoughts?
 
 -Brian
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )




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



Re: [Zope-dev] Zope on Linux and Database as MS-SQL Server on WinNT

2002-01-29 Thread Paul Everitt


Take a look at:

   http://www.zope.org/Members/haqa/XMLKit/news-1.1.1

Adrian made an interface to ODBC Socket Server.

--Paul

Peeyush Garg wrote:
 Hi,
 
  
 
 What's the current best solution to utilize the combination of Zope on 
 Linux and Database as MS-SQL Server running on WinNT. I don't find much 
 information searching the Zope web site. Can somebody point me to some link?
 
  
 
 Thanks,
 
 Peeyush.
 




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



Re: [Zope-dev] [BUG] Python 2.1.2 Zope 2.4.1

2002-01-28 Thread Paul Everitt

Leonardo Rochael Almeida wrote:

 I'm really disappointed with ZC for putting out a new release of Zope
 instead of a fixed version of the release most everyone is currently
 using.

2.4.4 is ready, but there's a problem with the Windows build.  I suppose 
we could just put the others up there w/out the Windows build, but then 
we'd wind up with 20 emails to reply to and explain over and over.

All in all, only a few days separate the two releases, and obviously CVS 
people have been able to get at changes all along.  Thus, I don't think 
this is an extreme case.

--Paul


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



[Zope-dev] FYI: Sprint schedule online

2002-01-15 Thread Paul Everitt


Whew, at long last, I've posted a Sprint Schedule at:

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SprintSchedule

Boy, that URL is too long.  I edited the dev.zope.org homepage to add 
links to the Zope3 page and the sprint schedule.  This page also answers 
the question, What is a sprint?

--Paul


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



[Zope-dev] Q: Anyone want to sprint in Fredericksburg next week?

2001-12-21 Thread Paul Everitt


Howdy.  This is a last-second email aimed at Washington-area Zope 
developers that might want to do a Zope3 extreme programming sprint with 
Jim next week, here in Fredericksburg.  The dates are any two of Dec 
26/27/28.  Good knowledge of Python and Zope development required.

Please reply to me today if you might be interested, and sorry for the 
last-minute notice.

--Paul


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



[Zope-dev] Re: My thoughts on the development process

2001-12-10 Thread Paul Everitt


I've taken a while to respond on this, because I wanted to talk it over 
with folks here, to think about the specifics of what different ideas 
would mean, etc.

In summary, your last paragraph says: So let's trade in some risks to
the Zope core development (rash action and messed up stuff
happening once every while), in exchange for a lot more active 
contributors.

We agree, and it's my job to get us there.  Here's the next level of 
specificity:

1) Lighter weight process.  Brian and I have talked about it, and we 
agree that we should investigate ways to lower the bar on ceremony, 
*without* abandoning organization.  However, we both feel that, as you 
noted, the ultimate issues lie elsewhere.  Thus...

2) Improve the tools.  There's merit to the argument that the state of 
the fishbowl isn't very discoverable nor usable.  Folks on zope-web know 
that we're proposing work that we'll do.  Also, we are open to work that 
others will do.

3) Delegate leadership.  This is, IMO, the most important thing.  We 
need more people in the core, leading important areas and making 
decisions.  For ZC, this really means that we have to trust the 
trustworthy and accept the paragraph of yours I quoted above.

4) Find the leadership.  We can't sit passively by and say, We opened 
CVS and nobody's done anything.  Somebody has to work specifically and 
repeatedly to bring people in, make sure they know what to do, and 
perhaps even prod them occassionally to get working.  This takes 
publicity, promotion, cajoling, communications, and all kinds of other 
things to get the momentum going.

I've signed up for the last part.

In general, I'm sure everyone is pretty talked out on this subject and 
ready to see some action and results to go with all the voluminous 
emails.  Me too.  So let this general state of the problem discussion 
rest for a while, and let's work on some of the good ideas already 
discussed.

--Paul

Martijn Faassen wrote:

 Hi there,
 
 I've read parts of the open letter threads just now. There's a lot of
 talk about how if only we have better tools the whole process will go
 better and Zope will get more contributors.
 
 That's a typical hacker response, and I do this myself as well.
 Throwing more technology at a problem doesn't always make a problem go
 away. And though technological solutions to social problems are nice if 
 you can have them, and we should look for them, they don't always work.
 
 I'm not convinced more technology will make the dead fish problem go
 away. I think the contributing process is in fact too heavyweight. It
 should be easier for people to get in drastic changes to Zope. The only
 way for people to take more responsibility if they can actually have it.
 Only a few people will take it, but that's more than what is possible
 now, with possibly the single exception of my taking responsibility for
 ParsedXML. And until recently I was still in the position of doubting
 whether I really had it formally, not just de-facto. I kept asking for
 approval and guidelines from the official maintainers, but they were too
 busy (no blame to them), so I went on anyway and did a release eventually.
 
 I dread having to go through the fishbowl to add in my 'node path'
 implementation to ParsedXML. I've done the design work,
 I've implemented most of it, and I feel I'd have mostly wasted time writing
 a fishbowl proposal. I hadn't even explored the problem enough to be able
 to do that. I needed to prototype it to understand it. I've discussed some
 issues with people locally and  and on the Zope-XML mailing list. And
 I'll probably release a version in a few days.
 
 Perhaps adding Formulator to the Zope core would be nice eventually. But
 going through the fishbowl bureaucracy would take forever. I only have so
 much time to spend on it, and I'd rather spend time improving the product
 itself.
 
 And now look at how the Zope core is actually being developed. Sure,
 there's lots of stuff in the fishbowl about what the Zope future should be like.
 Plenty of stuff, though some stuff is rather hard to find. But I have a lot
 of praise for what the Zope Corp people have accomplished it it; it's a lot
 better than having no such thing at all, even if it's only used as 
 a notification service in part.
 
 The main thinking about the directions of Zope is not done in the fishbowl or
 on the lists, it's in the minds of the talented people at Zope Corp and in
 the brainstorm sessions they hold together. That's the natural way people
 work. I work that way too. Such a process can occur on mailing lists as
 well, but it's very hard to break into it. I've tried several times.
 I'll keep trying as I'm convinced it's possible, but it takes a lot of
 persistence. Time will tell. On the Zope-XML list I just post regular updates 
 about my thinking to encourage discussion, and sometimes that works.
 
 So what am I trying to get at with this mail? One thing is that
 the process is too heavy-weight right 

Re: [Zope-dev] Re: core i18n support

2001-12-07 Thread Paul Everitt

Lennart Regebro wrote:


  Well, all the i18n developers will have a meeting early January in
  Europe with Jim Fulton in a 2-day brainstorming session.
 
  Excellent! When and where?

Yeh, cat's almost out of the bag on this one.  Here's the plan.  Note
that all of this is tentative!

As you may have read, we have been doing some Zope3 xp sprints
lately.  We're pleased with the results.

In fact, we'd like to start a pattern of opening up the sprints to
outsiders.  We'd like to invite folks to Fburg for a sprint.  Though
you'll pay your own freight, we'll supply a spacious cubicle. :^) If
you're interested, contact me.

Second, Jim is hoping to go to Europe first or second week of January
to do two sprints.  The first is with a small (3 plus Jim) group to
resolve the internationalization bottleneck and get Zope3 to do i18n
and l10n.  This first group will then help Jim do a larger (maybe 8)
sprint the subsequent two days for other people in Europe.  We haven't
yet arranged for facilities.

Third, we'd like to host an open house on the Thur and Fri after
IPC10.  Besides an open house, we'd like to have perhaps a massive
sprint.

Just to point out the obvious...this is a sign that we're listening on
this discussion and trying to lessen the difference between ZC and the
community.  With Zope3 we have a chance for key community people to
shepherd important pieces of the architecture.  These pieces can
include XML, i18n, cataloging, package management, workflow, etc.

At the same time, these sprints provide a working session with
face-to-face communications.  It's a high-bandwidth way to make sure
Zope3 does what the community wants.

--Paul


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



Re: [Zope-dev] Open Letters and Zope 3

2001-12-04 Thread Paul Everitt

Matt Behrens wrote:

 Shane Hathaway wrote:
 Again, this is all quite exciting and I hope you can join the action.
 
 I hope to.  Who's in charge of packaging and installation?  I see an 
 opportunity to do it right this time, I hope I'm not too late to the party.


I think this is an excellent area to bring in community members and let 
them have some ownership.  There are a number of interesting initiatives 
out there -- in no particular order, Andy McKay, Andrew Milton, Adrian 
Hungate, Kapil Thangavelu, and Amos Latteier.

We're interested in bringing more people into the core and giving them 
room to make decisions and have influence.  It's an important lesson 
from the discussions over the last few days -- we don't scale that well 
and we need more leadership in the core.

Thus, I'm looking for a couple of people willing to shepherd areas such 
as packaging and make a serious commitment for a fair duration.

--Paul

 



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



Re: [Zope-dev] Open Letter to zope-dev

2001-12-03 Thread Paul Everitt


Clearly this is a situation that has broken down.  I'll suggest a 
resolution in a private note to you in a sec.

--Paul

Toby Dickenson wrote:

 On Sat, 1 Dec 2001 08:50:14 -0500, Andreas Jung
 [EMAIL PROTECTED] wrote:
 
 
Also I had expect some input of the community regarding at unicode support
inside Zope. But there has been no feedback. It looks like no one needs
unicode support in Zope ?! :-)

 
 I see the smiley, but Im still not sure whether you are joking.
 
 Ive had stable, mature unicode support available as patches since Zope
 version 2.1. Im sure Andreas is familiar with them, we have discussed
 some details on more than one occasion.
 
 Ive expressed to DC several times that I am keen to get these patches
 into the zope core, and at Brian's request documented the changes in
 two fishbowl proposals (even that request seemed cheeky at the time;
 my patches were stable long before the fishbowl process ;-). He said
 he was keen to get something into version 2.3, then version 2.4, but
 so far nothing.
 
 
The opening of the CVS
is a good starting point but I would like to see more people contributing.

 
 So far it really does appear that nothing will happen about this
 particular issue until it is needed by a zope.com consulting project.
 If there is anything more that I can do then somebody please tell me
 what.
 
 
 
 Toby Dickenson
 [EMAIL PROTECTED]
 




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



Re: [Zope-dev] Re: Fishbowl?

2001-12-02 Thread Paul Everitt

Joachim Werner wrote:

 I think that there ARE problems that can not be solved on a mailing list or
 in the fishbowl. One of them is doing a good general design (which we MIGHT
 need for some of the Zope 3.0 issues). I followed all the stuff about the
 CMF and formerly PTK and knew that it was heading to a direction I didn't
 want, but at the same time I felt that it would not help if I just
 contributed to the mailing list. Maybe this was a personal problem of mine,
 but I don't think so.


I don't think so either.  I think your paragraph above does a wonderful 
job of concisely summarizing the challenge.

First, there shouldn't be Annointed Tools.  We should strive to have 
good tools, and we should strive to use good tools, but the real goal is 
communication.  If the current approach isn't hacking it, we need 
something else -- which could mean we learn from successful patterns in 
other projects.

Second, when communication reveals an issue -- what happens?  Let's say 
that every single person in the world of Zope agreed that the CMF was 
going in a wrong direction (just for the sake of argument, as the CMF 
has people that like it as well as dislike it).  Would anything actually 
happen if consensus was reached, and who would be the ones to convert 
conclusion into code?

Third, as Brian pointed out and you conclude with in the paragraph, 
frustrated people tune out.  This causes the other side of the 
communication to get frustrated and stop communicating.  Then things 
break down.  It's important to recognize this is happening, put aside 
the frustration, and address the problems.


 IMHO, there are two possible approaches to problems like that (major design
 issues I mean):
 
 a) dictatorship, if the dictator is really good in his job (e.g. Jim Fulton
 has done a great job with regard to the design of the ZODB )
 
 b) meeting in real live (or at least in real time)
 
 Some of the core architecture of the KDE KParts component model was
 developed on the KDE 2 conference AFAIK. I think we might have to do
 sessions like that at the upcoming Zope/Python conferences ...

That's a very good point.  It's even a good point inside ZC.  Getting 
ten people in a room for an extreme programming session has done wonders 
for our ideas on Zope3.  Anybody want to fly to Virginia? :^)

Yesterday morning I started hanging out on the #zope IRC channel. 
Already it has been illuminating.  It also creates an atmosphere of 
understanding.  I need to do this more often.

--Paul


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



Re: core i18n support (was [Zope-dev] Open Letter to zope-dev)

2001-12-02 Thread Paul Everitt


As both Robert and Joachim (in another message) have noted, core i18n 
support is blocked by a single issue: there are two different approaches 
  and insufficient consensus about resolving them.

The first criteria that I have is whether someone is willing to become a 
CVS contributor and shepherd i18n in a responsible fashion, as Martijn 
Faassen has done with XML.  In this sense we suffer from an embarassment 
of riches: both Localizer and ZBabel have people willing to step up and 
provide leadership.

Unfortunately there isn't someone with sufficient authority on the 
subject to annoint one as more right than the other.  And an arbitrary 
decision by ZC is sure to leave hard feelings.  Unfortunately this needs 
to get cleared up soon, so that an i18n team can start influencing the 
component architecture.

I suggest that Stefane and Juan David (Localizer/Nuxeo) and Stephan, 
Andrew, and Joachim (ZBabel/iuveno) have a little chat and make a 
recommendation for a small next step.

--Paul

Robert Rottermann wrote:

 Andreas,
 sorry if I have not reacted to a questions for assistance in the realm of
 i18n. I must have missed them.
 I rarely go to EuroZope since this site seems badly maintained.
 
 However I really would like to help with the internationalization of Zope
 since most of what we do here a my company must be multilingual.
 I do have considerable experience making programs translatable and I did a
 multilanguage CMF (with which I never was really happy)
 Some 6 Months ago I started to collect what is there regarding i18n and
 Zope. I did get a sizable number of answers. However there where two rather
 unfortunate tendencies:
 - multiple, different and incompatible attempts from our side
 - missing involvement and therefore no shepherding from ZC's side
 
 If, as Paul assures, the second point is about to be rectified it might be
 now the time to do a second such compilation and then start doing it.
 
 Robert
 
 - Original Message -
 
 From: Andreas Jung [EMAIL PROTECTED]
 To: Joachim Werner [EMAIL PROTECTED]; Paul Everitt [EMAIL PROTECTED];
 Robert Rottermann [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Saturday, December 01, 2001 2:50 PM
 Subject: Re: [Zope-dev] Open Letter to zope-dev
 
 
 
- Original Message -
From: Joachim Werner [EMAIL PROTECTED]
To: Paul Everitt [EMAIL PROTECTED]; Robert Rottermann [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, December 01, 2001 08:22
Subject: Re: [Zope-dev] Open Letter to zope-dev



The second is pretty exciting as well.  I saw a presentation in Paris

 by
 
Juan David Palomar, of Localizer fame.  (The presentation is now up at
http://estce.act.uji.es:9673/localizer).  The presentation impressed

 me
 
on the need to get someone into the core of Zope that knows all these
details, but also convinced me that the Zope3 effort needs to

 anticipate
 
the needs of i18n and l10n.

ZBabel and Localizer are good starts, but as jdavid says, both should

 be
 
thought of as non-core projects that start influencing the core
step-by-step.

Hi!

I fully agree that ZBabel and Localizer don't have to be core projects

right

now. But the core must be made fit for i18n to make sure that we don't

have

to patch things like the user folder implementation or the Help! button

 in
 
the code. In Zopw 2.5, there still seem to be hot spots to fix with

regard

to i18n.


Of course there are hot spots. I have asked multiple times for help on the
mailing
lists and the Eurozope site to identify such related hot spots.
Also I had expect some input of the community regarding at unicode support
inside Zope. But there has been no feedback. It looks like no one needs
unicode
support in Zope ?! :-) Anyway, as a first step Zope 2.5 provides full
unicode
support for the ZCatalog. I would like to see some volunteers that could
help
to set up a list of requirements (the list is almost there on the Eurozope
site
I think) and possible solutions that could be integrated into the Zope

 core.
 
Referring to the open letter to zope-dev I could also charge the

 community
 
for zero feedback. But this is not the place and time for flamewars.

 Instead
 
we should bundle the power of ZC and the community. The opening of the CVS
is a good starting point but I would like to see more people contributing.

Cheers,
Andreas







 




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



Re: [Zope-dev] Another open letter. :-)

2001-12-02 Thread Paul Everitt

Danny William Adair wrote:
[snip]
  Have you seen this interview?
  http://www.zopera.org/site/Members/odeckmyn/iv_paul_2001 (recently
  announced on this list)
 
  Quote: Regarding CMF, we expect it to disappear in its current
  form, ...
 
  Introduced to us as the Portal Toolkit, later labeled as probably
  evolving into a commercial product (couldn't find it in the
  archives when I tried a minute ago, but I know I wasn't dreaming
  when I read it), then renamed to Content Management Framework and
  the out-of-the-box solution for site developers that need
  membership, skinning, an easy content management interface, and
  pluggable add-ons, Paul Everitt now calls it a big prototype for
  the new architecture. Although I think that this is not how it all
  started, not even how it meant to be less than a year ago, you see
  that your concerns are no longer something to worry about. The
  good things will be taken to the Zope core, the rest will remain
  interesting only for people who actually implement.

Yikes!  I need to get a clarification back to Olivier regarding my point 
on all this.

First, the PTK/CMF evolved separately from Zope, which made it move 
pretty quickly.  All along with thought in terms of the PTK/CMF trying 
out things that the more conservative Zope development wasn't going after.

As we started thinking about Zope3 and a component architecture, we took 
a look at some of the ideas in the CMF and felt they were a valid 
approach.  As such, the CMF could be thought of as a shipping prototype 
for ideas that will make it into Zope3.

It's true that much of the CMF code should disappear if Zope3 does its 
job.  Perhaps around 50% of the Python code, for instance.  The 
remainder is in areas that we had mixed success on anyway -- namely, the 
CMFDemo portal doesn't really try to be an out-of-the-box finished 
product.  Most of us would be thrilled to see a different killer app 
develop that took the place of this in Zope3.

Certainly existing CMF users shouldn't be worried.  For instance, we're 
planning two important customer engagements that are _just_ starting 
which will be CMF based.  We want to work with people doing projects 
similar to the CMF and get some common ideas/machinery into the 
component architecture.

Regarding the PTK possibly becoming a commercial product...well, some 
evolutionary paths are dead ends. :^)

--Paul


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



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Paul Everitt


Agreed completely on both of those points.  There's double good news on 
both:

1) Someone plans to do something about it.

2) Both are with community involvement.

On documentation, someone in the community has committed to taking over 
the Documentation page on zope.org and finally organizing the myriad of 
useful, but unlocatable, doc resources out there.

The second is pretty exciting as well.  I saw a presentation in Paris by 
Juan David Palomar, of Localizer fame.  (The presentation is now up at 
http://estce.act.uji.es:9673/localizer).  The presentation impressed me 
on the need to get someone into the core of Zope that knows all these 
details, but also convinced me that the Zope3 effort needs to anticipate 
the needs of i18n and l10n.

I spoke with the guys here doing the extreme programming session on 
Zope3, and they agreed.

To say it again:

1) I think the world of Zope needs to grow 10x in the next year.

2) ZC can't do it, and much of the action in Zope is non-U.S., 
particularly Europe.

3) Thus, Zope needs a strong, competitive internationalization story.

ZBabel and Localizer are good starts, but as jdavid says, both should be 
thought of as non-core projects that start influencing the core 
step-by-step.

--Paul

Robert Rottermann wrote:

 Friends,
 first thing I want is to express my huge gratitude to have something 
 like Zope and its community.
  
 I have read all the all the mail that has been stirred by that open 
 letter.
 I agree very much and I am willing to contribute as much as I can that 
 zope should grow 10x.
 I found two things missing in the discussion so far that are crucial to 
 attain this goal:
  
 - documentation
 To start using Zope doing something more than trivial is an incredibly 
 frustrating thing. Hunting for the right piece of documentation is very 
 very hard. The community is very helpful I agree readily. However asking 
 it should be the last resort and being forced to use it as an important 
 part of the developement effort is very cumbersome and time consuming. 
 And does not really take the frustration out of the process.
 Bruce Eckels postings to this list show that even a developer of his 
 statue is prone to the same effect.
 I am a seasoned programmer that started to deal with Zope exactly one 
 year ago. It is only now that I learn where to look for what piece of 
 information and to decide which one is relevant and which one is not.
  
 - translation support
 Internationalisation is crucial. English in the user interface is just 
 not tolerated in a non English speaking part of the world. It is 10 
 years ago something like that would have been acceptable. I am from 
 Switzerland where we pride ourselves to be multilingual (6 Million 
 inhabitants 4 major languages, English being the fifth). However nobody 
 would think of having anything like English on a public website.
 There are a number of efforts towards translation support. However to 
 have any of them to succeed it needs the support of ZC which just does 
 not exist.
  
 Now I have to hurry getting breakfast
 (or I get into troubles)
  
 Robert
  
  
 
  
 
 
  
 




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



[Zope-dev] Re: Fishbowl?

2001-11-30 Thread Paul Everitt

Chris Withers wrote:

 Paul Everitt wrote:
 
Moral: there's a difference between correct and right.  While we might
have good reasons for inattention, it will surely lead to an
unsatisfying conclusion.  Thus, ZC needs to be smaller part of a larger
Zope, IMO, and do this by spending more time helping the community take
over parts of Zope and the Zope world.

 
 Well, this is a purpose, which is good.
 
 I'd say sorting out the Fishbowl would be a good action to start with.


You're going to love the irony on this, but there's a proposal in the 
fishbowl on this:

   http://dev.zope.org/Wikis/DevSite/Proposals/FishbowlManageability

...and of course, nobody knows the proposal is there.


 Now, I see options for this:
 
 1. We can build something better. I can list requirements but that's not relevent 
here. However, this will take serious
 effort (it's a hard problem...) and as we know from bitter experience, things that 
need serious effort either don't
 happen, take far too long to happen or happen badly ;-)


Yep.  I'm in favor of some very small, very incremental steps.

 
 2. We could by a tool that does this kind of thing. Where would we get such a beast 
from? how much would it cost/ who
 would fit the bill?


...and what would be the transition costs?


 3. We could use another open source tool. Bugzilla springs to mind. Yes, it's not 
Zope, or even python, but it does
 work, certainly better than anything we, as a community, have right now or could 
build in the time it would take to
 install and set up.


Hmm, I don't really see Bugzilla and the Fishbowl overlapping.  Perhaps 
with the Collector, though.  However, I don't think the real issues 
involved are related to choice of tool.

It's been mentioning that ZC doesn't pay attention, so proposals go in 
and nothing happens.  Bugzilla won't fix that problem.  I'll add that 
the community doesn't always pay good enough attention.  Sure, people 
will say when will we have versioning or when will we have web 
services.  We go off, make a proposal, and email zope-dev.  No feedback 
-- I take that back, each has received one response, whether by wiki 
comment, mailing list response, or private response.

This isn't a good track record.  Brian produced 35 pages worth of 
almost-flawless docs on web services to go with his code.  But no 
comments.  And he's doing this on his own time.  So let's remember that 
this is a two-way street.

IMO, Bugzilla won't fix these kinds of problems.  I think the first step 
is to refine what we have while finding better ways to work together.


--Paul



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



Re: SV: [Zope-dev] Fishbowl?

2001-11-30 Thread Paul Everitt

Casey Duncan wrote:

 I propose (as I just did on zope-web) that ZC do one more little thing for 
 us. Open the web infrastructure up to a few of us. I would be willing to 
 spend a few nights hashing out a more active fishbowl system if that's 
 what's important. Lets take that first step though.

Sold.

Get a group of four or five people that are willing to commit up to ten 
hours a week for the next month.  Gather together on zope-web and talk 
about what you plan to do.  When rough consensus is reached, we'll give 
you logins on the test server.  When consensus is reached there, we'll 
give you logins on zope.org, because at that point, you'll have 
convinced yourself and others that you're in it for the long haul.

It's easy to start.  Subscribe to the zope-web mailing list:

   http://lists.zope.org/mailman/listinfo/zope-web

...and start discussing what needs to be done.

--Paul


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



Re: [Zope-dev] Zope has been Hijacked! Save Zope!

2001-11-30 Thread Paul Everitt

Chris McDonough wrote:

Those who know of these problems can write clean applications but

 these
 
issues are kept strictly
confidential.

 
 Isn't this dangerously close to a conspiracy theory?

Yes, he's right -- we hid the information on this top-secret thing 
called the World Wide Web:
   http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution

Muhahaha!

--Paul


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



Re: SV: [Zope-dev] Re: Fishbowl?

2001-11-30 Thread Paul Everitt

Magnus Heino wrote:

  Well, that checkin was done to the cvs 4 days ago. If you haven't
  read the one line at dev.zope.org about it being available in the
  cvs, or if you dont subscribe to the cvs mailinglist, how are you
  supposed to know that it exists? :-P

Actually, he sent an email to zope-dev on 11/26.  Version control went
to zope-dev on 10/23.  Between the two, one email of discussion.

This is why I'm leery of thinking this is simply a tool issue.  I think 
we'll need more creativity, hijacking notwithstanding. :^)

--Paul


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



Re: SV: [Zope-dev] Re: Fishbowl?

2001-11-30 Thread Paul Everitt

Magnus Heino wrote:

This is just a guess, but I suspect that this is a sort of unfortunate 
cycle developing: people post proposals, get (understandably) dismayed 
at the response time and end up not spending much time there, either 
contributing or providing feedback.

 
 Well, lets move this discussion to a wiki and see how it goes...
 
 This is a tool issue.


I'd like to propose this crazy tool called email. :^)

Anybody that thinks they'd like to participate in the building of a 
better fishbowl (particularly if your name is Chris :^), trot on over to 
[EMAIL PROTECTED]  Let's hash it out, perhaps starting with Ken's 
proposal.  Let's then make a proposal back to zope-dev and see what 
people think.

--Paul





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



Re: [Zope-dev] Re: Fishbowl?

2001-11-30 Thread Paul Everitt

Brian Lloyd wrote:

[snip]


  When we first opened the fishbowl, it was with the certainty that we
  wouldn't get it right immediately. That's why we went with the
  intentially low-tech approach of a pile of Wikis. That first step
  actually worked pretty well for a while until we hit
  critical-Wiki-mass and there were suddenly too many proposals /
  projects to follow easily. So please don't think that we are
  somehow attached to the current fishbowl implementation as some
  sort of be-all-end-all.
 
  When we first put it in place, we were minimal with the fishbowl,
  applying Jim's second law of engineering (You can't solve a
  problem until you know the answer.) Now I think we a lot more
  about the answer:
[snip]

This bears repeating: the fishbowl was _never_ intended to be thought of 
as a tool.  Rather, it should be thought of as an approach, methodology, 
or culture.  You can rip out the Wiki and replace it with the Collector 
or Bugzilla, and you'd still have the fishbowl.

Months ago we reached critical-Wiki-mass.  However, we've now reached 
the point where some people are volunteering to do something about it.

--Paul


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



Re: [Zope-dev] FW: Zope optimistic transactions.

2001-11-30 Thread Paul Everitt


Below is the one response to your message, by someone from ZC.  I find 
it hard to locate the parts about censored in a way that would not be 
allowed for most commercial products, the discussion was quickly moved 
line, and these issues are kept strictly confidential.


Please read one or more of the following:


http://www.amk.ca/zodb/zodb-zeo.html
http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution
http://www.mit.edu/afs/sipb/project/python/doc/DevGuide/Persistence.html

They describe the ZODB and its optimistic concurrency strategy in 
detail, and should answer any questions you may have about the purpose 
and handling of ConflictErrors.  They also contain (or link to) other 
information that you really should know before attempting to analyze the 
ZODB in any depth.


--Paul


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



Re: [Zope-dev] (SHOUT) NOTIFICATION!!!!

2001-11-30 Thread Paul Everitt


I agree that we have to lower the bar.  What Seb and I were discussing 
is a commitment from a small group of people to help accomplish lowering 
the bar.  Once it's lowered, then hopefully the rate and impact of 
casual contributions will greatly increase.

--Paul

Andrew Kuchling wrote:

 On Fri, Nov 30, 2001 at 05:57:17PM +, seb bacon wrote:
 
What we need, as Paul suggested about zope-web, is a set of community
members who are able and willing to contribute 10 hours per week.  I
think there are very few such people.  I would love to, but I simply

 
 I'd think the number of such people is zero, except for people who use
 Zope in their work and can justify time spent developing on Zope
 itself as being work-related.  It can't be assumed that people have
 much time to spend on a free software project; instead you have to
 lower the bar, and make it easier for hit-and-run contributors.  If it
 takes days or worse, weeks and months, to get a contribution accepted,
 people just won't bother. 
 
 Re: bug tracking.  If Bugzilla is too much of a bear to deal with,
 there are simpler alternatives available, such as Roundup, Jitterbug,
 the SF bug tracker, and our unreleased SPLAT!.
 
 --amk
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 




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



Re: [Zope-dev] Open Letter to zope-dev

2001-11-30 Thread Paul Everitt


Chris was just drinking a beer with us at Orbit's twenty minutes ago, 
and now he's responding to email on a Friday night.  That's just sick. 
I don't think your boss fully appreciates you, number 27. :^)

--Paul

Chris McDonough wrote:

 The session management framework (formerly known as 
 CoreSessionTracking, now
 it is in the core and just called Session) is another example, if my 
 first
 look was right. The API seems to have changed a lot between the last 
 CST and
 the final Session release that is part of 2.5 beta. O.k., there still 
 seems
 to be some backwards-compatibility, but why can't those projects be more
 public? The tools are there (like CVS) ...
 
 
 Mea culpa.  One of the problems is that that nothing gets by the BDFL 
 here (Jim), and he required some of the changes.  But I admit that I 
 should have kept the fishbowl project more updated.  I did update it 
 (lamely), but not well enough.
 
 -= C
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




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



Re: [Zope-dev] Fw: [Exuserfolder-devel] Zope 2.5b1 release

2001-11-29 Thread Paul Everitt


Yikes, it was pointed out to me that I typed amk instead of akm. 
Though I knew it was Andrew Milton and not Andrew Kuchling, I mixed up 
the letters.  (In fact, as I was typing it, I was thinking wow, that 
looks like Andrew Kuchling's monogram.)

--Paul

Paul Everitt wrote:

 
 Whew, that email (and the preceding one in the thread) is quite a 
 whopper.  In substance, amk raises some pretty serious issues that we 
 need to come to grips with very quickly.
 
 I don't have enough information to respond right now, but trust that 
 we'll get a good response back today.
 
 Neo-moderator note: if the discussion _does_ start over here, everyone 
 is advised to leave the anger at the door.  Problems like this can 
 usually be solved pretty easily by direct communication and open minds.
 
 --Paul
 
 Dario Lopez-Kästen wrote:
 
 I thought this might be intresting for discussion on zope-dev as well...

 /dario

 - Original Message -
 From: Andrew Kenneth Milton [EMAIL PROTECTED]
 To: Andrew Kenneth Milton [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Thursday, November 29, 2001 8:45 AM
 Subject: Re: [Exuserfolder-devel] Zope 2.5b1 release

 It has been pointed out that perhaps the dripping sarcasm drowned out the
 acutal points of the email, sorry I was particularly pissed off at how
 half-assed it all was.

 If you are writing a product that needs to create a user, you go look in
 User.py and find out what the API since that tends to be the only place
 the API is documented.

 If you look at how UserFolder is implemented;

 a) The change to manage_* seems to be completely arbitrary, since we 
 already
had _do* methods that meant you didn't have to call manage_users with
fake submit buttons. So what is the point of having manage_ ?

 b) manage_* methods usually indicate web callable methods, which these
 clearly
aren't (no docstring, no REQUEST parameter). In fact they don't 
 return a
 status
at all, so they seem to doubly useless.

 c) If it's an internal API for applications then the methods should 
 probably
be protected by being prefixed with an _ to indicate they're not for
 calling
from the web or from within Documents/Templates.

 d) Even if you conformed to the API by calling e.g. manage_addUser() this
seemed to be incorrect, since it didn't do things like encrypt the
 password.
This meant you would have to either a) encrypt the password yourself
(*very bad for XUF*), or b) call _addUser() which is not part of a
 defined
API but looks like it should be (i.e. manage_addUser and _addUser 
 seem to
be reversed in functionality).

ii) This is compounded by the fact you would have to query the 
 UserFolder
itself to find out if you should be encrypting passwords (what no
UserFolder capability API?).

 e) s/_do/manage_/ doesn't constitute a new API. It's just the old one 
 with
 the
names changed.

 f) We've done a lot of work to make a flexible UF product that is I18Ned
(well -able), and they still use the value of the submit button. I 
 would
 have
expected to see an alternative manage_users called from the ZMI that
behaved much better, with manage_users calls raising warnings.

 g) Someone got paid to do it, and that just pisses me off, given the 
 quality
of the stuff we release for free (and I'm still looking for a job btw
 d8).
We're not perfect, the 0.10.1 release shows that, but, at least we
spent more than three minutes including thinking time on it, and I at
 least
try not to change things just for the sake of it.

 Anyway. In case you were wondering what the previous email meant, there's
 the
 actual meaning d8)

 -- 
 Totally Holistic Enterprises Internet|  | Andrew 
 Milton
 The Internet (Aust) Pty Ltd  |  |
 ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe 
 Daemon
 PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]|

 ___
 Exuserfolder-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/exuserfolder-devel



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

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




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

Re: [Zope-dev] FYI: Zope version control project

2001-10-23 Thread Paul Everitt


We misfired on an Apache configuration and the Apache's weren't 
listening.  It should be back.

--Paul

Chris Withers wrote:

 Brian Lloyd wrote:
 
Hi all -

We've started a new fishbowl project to address version control
in Zope:

http://dev.zope.org/Projects/Wikis/DevSite/Projects/ZopeVersionControl/

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




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



Re: [Zope-dev] not Python 2.2a1 but Python 2.2b1

2001-10-20 Thread Paul Everitt


An important aspect to consider: in some cases, you simply need the ZEO 
storage server to have large file support.  Thus, if you can get the ZSS 
running under Python 2.2, then you're set.  This is considerably less 
ambitious than getting all of Zope (e.g. the catalog) migrated to a new 
Python version.

Also, since Barry and Jeremy (or, as we say, Barremy) are now calling 
the shots on ZODB and ZEO, you can bug them about it. :^)  They're 
likely to care a lot about keeping everything in track with Python 2.x.

--Paul

Martijn Faassen wrote:

 Hannu Krosing wrote:
 
Andy McKay wrote:

Is out and:

Large file support is now enabled on Win32 and Win64 platforms, and
automatically configured (at least on Linux and Solaris).

Cool, that will mean there will be less worries about Zope users hitting the
2 gig limit.

But will Zope 2.4.x run on 2.2 ?

 
 No guarantees, but I do know the PythonLabs crew and the Zope development
 crew try to keep things working with 2.2. That doesn't mean there won't
 be problems, but I don't suspect it'll be as tricky as the move from
 1.5.2 to 2.1. The main thing is that the Zope C extensions keep working, but
 that seems to be watched fairly carefully.
 
 So, perhaps yes, perhaps no, but don't expect a long period of Zope trying
 to catch up with Python again.
  
 Regards,
 
 Martijn
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 




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



Re: [Zope-dev] ZPublisher/ZServer interaction (was Re: A modest proposal)

2001-10-13 Thread Paul Everitt


I don't know, there were quite a lot of ideas brought up.  It started 
with a discussion of Twisted being swappable for Medusa.  Since Itamar 
is a developer of Twisted, he should champion that effort (he knows a 
lot more Zope than any of us know Twisted).

There was also a discussion about replacing Medusa by embedding in 
Apache. While Michel said we had thought about it, that's about the 
extent: we've thought about it.  It isn't even scheduled for further 
thinking at this point.

I think the best thing is for some people that care deeply about this to 
go off and prototype a little bit and see what's involved.

--Paul

Andy McKay wrote:

 So did we at least get a fishbowl out of it?
 
 Cheers.
 --
   Andy McKay.
 
 
 - Original Message -
 From: Paul Everitt [EMAIL PROTECTED]
 To: Phillip J. Eby [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Friday, October 12, 2001 7:23 AM
 Subject: Re: [Zope-dev] ZPublisher/ZServer interaction (was Re: A modest
 proposal)
 
 
 
Wow, this is one hell of a thread. :^)

FWIW, Grisha put a Bobo publisher in mod_python a couple of years ago.
Thus, if you like ZPublisher-style processing, you can do it in Apache
via mod_python.

I outta contact him and see if he'd consider putting page templates in
mod_python.  Might be good for both page templates and mod_python.

--Paul

Phillip J. Eby wrote:


At 08:00 AM 10/10/01 -0700, kapil thangavelu wrote:


sadly the distinction between zpublisher and zserver is nowhere near as
clean, i spent some time looking at it this morning trying to get my
server
of choice using zope. i thought it would be a mid morning hack, but
the rabit
hole follows the class heirarchy deeper and deeper:).  all i have to
show for
my results is zope's output dumped to the server logs. its a start
though...

hopefully we get some new religion in the publisher, please...


Hmm...   Check out:

http://cvs.eby-sarna.com/pylib/ZLite/

Specifically, the ZPlumbing module, for several examples of ZPublisher
run loops using CGI and two different FastCGI modules.  I don't know
anything about Twisted, so I couldn't tell you how easy it'd be to use
the ZLite framework for this.

ZLite is the beginnings of my work on a Zope Lite distribution.  It's
sort of the Standalone ZODB distribution's evil twin - intended if you
want to use almost anything *but* the ZODB and ZMI parts of Zope.  That
is, when you just want the app server without the IDE and application
framework.  Architecturally, it's intended for multi-process, single
thread setups using Apache as a front-end, with FastCGI.

This shouldn't be considered an announcement or a release, btw.  The
code in CVS is production-hardened by years of service (many millions of
hits served), but is utterly without documentation, nor has everything
I've written been checked into CVS yet.


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




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


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




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



Re: [Zope-dev] ZTables and/or Catalog plugable brains?

2001-10-05 Thread Paul Everitt

Martijn Faassen wrote:

 I'm not entirely sure why the idea of ZTables went away so completely. 
 Python tables in the ZODB combined with the catalog should make for an
 interesting system to play with. Though perhaps there are products
 out there that actually do this. Come to think of it, MetaPublisher
 (not to be confused with MetaKit) can use a ZODB backend, can't it?

ZTables was a Zope1 product.  We never updated it for Zope2.  There's so 
much new machinery in Zope, particularly regarding indexing, that 
ZTables would really only serve as interesting requirements input.

I certainly think that some kind of generic table tool in Zope would be 
useful.  I'm sure that others could do a better job of it than ZTables 
did, in light of all that's happened in Zope and the CMF since then.  In 
fact, Formulator probably has a role as well.

--Paul


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



Re: [Zope-dev] Zope on Windows/Mac OS X: BatteriesIncludedDistribution

2001-09-28 Thread Paul Everitt


Whew, what a proposal and what a good sign!

As several have noted, there are quite a few proposals in the fishbowl 
that deal with different aspects of the problems.  There's also a draft 
proposal that we had here in ZC that expands on the items.  Finally, 
there appear to be a few pieces of software (yours, zctl, zopectl, etc.) 
that try to address aspects.

I suggest that we all spend some time trying to revisit all the 
proposals, obsolete the ones that are covered elsewhere, and try to find 
the common ground.  There is a dorman zope-packagers mailing list we 
could hijack for these purposes:

   http://lists.zope.org/pipermail/zope-packagers/

I think, with all the various efforts, it is time to agree on some 
standards regarding where configuration data lives and how it looks.

--Paul

Richard Jones wrote:

 I've just created the follwing fishbowl proposal:
 
   http://dev.zope.org/Wikis/DevSite/Proposals/BatteriesIncludedDistribution
 
 Please read and comment.
 
 
 Richard
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 




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



[Zope-dev] Re: [DISCUSS] Committer agreement not even handed and threadening

2001-09-28 Thread Paul Everitt

Dieter Maurer wrote:

 Paul Everitt writes:
  http://dev.zope.org/CVS/Contributor.pdf
 
 The Committer Agreement does not seem to be even handed:
 
The committer transfers rights immediately and indefinitely
to Zope Corporation (the contributions become a gift to
Zope Corporation).


This is an inaccurate representation.  Transfer means you lose the 
rights and we gain the rights.  Under joint ownership, both have rights. 
  I think this point was abundantly clear, so I'm surprised to see you 
portray this as a gift.

The agreement states explicitly that no rights are transfered
to the committer.


Because they never lost any rights.


This is not a problem in itself. However
 
   My intention to contribute would be to strengthen
   the Open Source Movement. A statement that
   the supported code base (Zope) will remain open source
   and that committers will be able to use it (indefinitely)
   under terms comparable to the current ZPL would
   help to let the agreement to appear more balanced


I don't think it's really feasible to 100% guarantee things in the 
future.  Rather, the agreement states that current code, and any 
contribution, will be available under the ZPL.  Nothing can be 
retracted.  If someone comes along and gives us one trillion dollars to 
stop releasing our work as open source, two things would happen:

1) First, we'd take the money. :^)

2) Second, all the existing code has to remain available under the ZPL. 
  We just wouldn't do _new_ things under a ZPL.


This is part of the safety of joint ownership.  If you don't like what 
we do in the future, you still have rights on your contribution.


 The Commitrer Agreement is quite threadening:
 
A committer takes over a considerable risk (complete warranty
and indemnification with respect to intellectual rights infringement).


Yes.  You can't make the risk disappear.  Someone has to bear the risk. 
  It makes zero sense for ZC to bear the risk of what goes on in someone 
else's brain.  Even in the scenario of carelessness, a case will have to 
be made regarding what you knew and when you knew it.


The risk is far higher than that of a (german) employee.
German employment law recognizes that
 
  *  all people make (sometimes) errors
  *  coping with isolated errors is far easier for
 a larger community (the big employer) than
   a single individual.
 
Therefore, it uses the term Fahrlässigkeit (carelessness).
An employee has to take all care to not make errors during
his work. If something bad happens due to slight
carelessness (leicht fahrlässig), then this is
a general risk which has to be taken by the employer.
If serious carelessness (grob fahrlässig) was the cause,
then the employee has to take the consequences for himself.

 

We should have something similar for the committer agreement
(not restricted to intellectual property rights!).

 

Maybe something like an insurance for slight carelessness
cases...


Unfortunately we'd have to be the insurer. :^(


Otherwise, commiting anything might easily ruin an individual.


Instead, you'd prefer that it ruin ZC?  Or are you asserting that 
somehow we could make it so that nobody would be held accountable?


Especially with the strange US Patent Laws (where almost
everything (such as presenting information in a popup window
or integrating a Web Frontend with a baking oven) can
be patented) and incredibly high damages amounts
(5 billion for a smoker who got cancer) assigned in US courts.


Unfortunately that's the jurisdiction in which we operate.


--Paul



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



Re: [Zope-dev] Multithread transaction problems in ZODB

2001-09-26 Thread Paul Everitt


First, just a friendly reminder that there is a zodb-dev mailing list. 
On this, check out Andrew Kuchling's page about ZEO development:

   http://www.amk.ca/zodb/zodb-zeo.html

There's a section at the bottom with a brief discussion of 
ConflictError, what it means, and how to handle it.  Zope automatically 
does the retry, but Python develops have to handle it themselves.

Here's a link with some information about what's known as application 
level conflict resolution:

  http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution

There's also some discussion at:

   http://www.zope.org/Documentation/Articles/ZODB2

Hope this helps...

--Paul

Cyril Elkaim wrote:

 Hi,
 
   We are testing ZODB directly from Python and have a multitread 
 ConflictError problem.
 
   In short :-) if we open a connection in a first thread, then a second 
 connection in a second thread and then commit the first one and then the 
 second (the transactions are so interlaced)...
 
   Not only we have the ConflicError, even if obviously we do not modify 
 or create the same objects. But in fact the last transaction doesn't 
 even have its own objects saved.
 
   We are using ZODB from Zope 2.4. We have a similar problem using 
 Berkeley Storage too (beta4).
 
   If the two threads are serialized eveything works fine (but that's no 
 more multithreading no? ;-)
 
   So is it possible to access ZODB from a multithreaded application?
 
 
 Thanks in advance
 
 Cyril Elkaim
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




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



Re: [Zope-dev] DISCUSS: Community checkins for CVS

2001-09-25 Thread Paul Everitt

Martijn Faassen wrote:


  http://dev.zope.org/CVS/Contributor.pdf

 
 This says 'you must indicate your agreement to the term below'; shouldn't
 it be 'terms'?


Uhh...well...yes!  I'll make the change.  I'm waiting for news back from 
the lawyer about provisions for handling patches.  I'll then post a new 
rev of the materials.

Does anyone think this is close enough that I can go ahead and get the 
bootstrap group (under ten, selected by us) going?  I'd like to avoid 
making them sign and mail an agreement, then do it again if there's 
substantive changes.

--Paul





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



Re: [Zope-dev] RE: Barriers to Zope popularity: Part 2: source control

2001-09-25 Thread Paul Everitt


I'd like to add some misinformation...errmm, comments. :^)  On the 
version control side, you're quite right, we're still behind on it. 
There _are_ some ways to get there, if you try hard enough.  But that's 
unacceptible.

There are two things long term that need to be done: filesystem 
synchronization and version control.  The former is a project to make it 
possible to represent and perhaps round-trip Zope data in a way friendly 
filesystem tools and patterns.  This obviously includes SCM systems like 
ClearCase.

We've had, at our Friday jam sessions, a couple of proposals on this. 
So far it's simply provoked rigorous discussion but not a lot of 
consensus, as balancing the competing goals is harder than it sounds.

I was talking with Jim yesterday over lunch about this, and whether the 
new component model would put filesystem synchronization in its scope. 
The short answer is, not in the first cut.  It will certainly make 
filesystem synchronization a lot easier, but we need to get it out the 
door and tackle filesystem syncing later.

Regarding version control...this is something that has been burned into 
our skulls in recent RFPs that we've responded to.  It's the number one 
thing we at ZC need to address to be more competitive in CMS bids.

So far the goals and use cases of DeltaV seem to best describe what 
we're currently thinking:

http://www.webdav.org/deltav/
http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt
http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm

Note that this is for Zope itself to have a model for version control. 
Filesystem sync is the most obvious way to interface to a separate SCM 
system.  However, _if_ Zope adopted a repository model, it's conceivable 
that Zope could have an implementation of the repository that used an 
external system.  _Please_ understand that this is all hand-waving right 
now.  But I'm on the hook to incept versioning, so it's informed 
hand-waving. :^)

--Paul

Jay, Dylan wrote:

-Original Message-
From: Kenichi Sato
Sent: Monday, 24 September 2001 5:49 PM
To: djay
Subject: Barriers to Zope popularity: Part 2: source control


Dear Mr. Jay, Dylan,

I am Ken Sato, a manager of software development projects. I'm now
taking a look at Zope as a tool to publish project related
information internally.

Zope looks nice but I found it has two potential problems.

 1. WYSIWYG editing
 2. Source control (by ClearCase)

Then, I found that you pointed out exactly same things in the
zope-dev mailing list.
(http://lists.zope.org/pipermail/zope-dev/1999-September/001602.html)

Because the post was two years ago, I wonder if you have already
solved the above problems. It would be very helpful for me if you
could give me some information on this issue, please.

 
 Hope you don't mind me CC'ing this to zope-dev. I still see both these
 issues as important and still see the lack of progress towards Zope working
 well in traditional development environments being a real outage. Plus
 others may have different opinions about the current state of affairs
 
 1. I have not used Zope Page Templates but these are supposed to solve the
 wysiwyg problem. They are an alternative to DMTLDocuments. They allow for
 much better seperation of code and presentation. Get you graphics people to
 use webdav to edit the html with whatever editor they want and the coding
 people argment the html rather than rip it appart.
 http://www.zope.org/Documentation/Articles/ZPT1
 
 Personally I like DTML and back then I did suggest a way DTML could used in
 a similar way to Page Templates (basically have a view mode of a DTML
 document that incorparates the rendered content as well as the DTML code
 such that when the page is edited and saved back, it will save all the
 changed parts back to the where they came from, i.e. the different
 DTMLMethods that made up the page). but like most of my ideas I din't have
 the ability or time to implement it.
 
 
 2. Hasn't really been solved. There are sort of attempts that work now with
 CVS (I havn't tried it)
 http://www.zope.org/Members/sspickle/ZCVSMixin
 This 
 
 but there are proposals that will better solve this problem, but no
 implementation on the way that I can see.
 The problem is really one of synchronization. You want two different
 representations that are both kept upto date. One for zope to use, one for
 all the reasons we have things under source control. You may or may not want
 control of when the synchronization occurs.
 
 Here are some related proposals
 
 http://www.zope.org//Wikis/DevSite/Proposals/SynchronizationMechanismZCVSMix
 in
 
 http://www.zope.org/Wikis/DevSite/Proposals/SynchronizationTab
 
 http://www.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst
 em
 
 I also see a lot of parallels with the work going on with ZODB replication.
 If you had replication between a normal ZODB and some filesystem source
 control ZODB then you would have the source control 

Re: [Zope-dev] DISCUSS: Community checkins for CVS

2001-09-25 Thread Paul Everitt


OK, a response.  Sorry for the delay.

First, I'll change the part of the introduction that says:

  Essentially, a committer signs an agreement stating that all
code that the committer submits has been created by her.

...to say:

  Essentially, a committer signs an agreement stating that all
   code that the committer submits has been created by her, or
   that she has verified that the contributed code violates
   no rights.

Which means that we're going to take you up on your suggestion for 
encouraging small patches.  I just added this to the FAQ:

   8) Does someone have to jump through all these legal hoops just to
   submit a small patch?

 The contributor agreement certainly is a heavy process for someone
 that wants to make a small contribution, such as a patch.  These
 contributions are just as important to the health of an open
 source project as major code work.  Thus, Zope should encourage
 patch contributions, not create an enormous disincentive.  At the
 same time, integrity of the code base needs to be maintained.

 For small contributions, simply supply them through a
 communications channel such as the bug tracker or the mailing
 lists.  Alternatively, contact a committer or ZC directly.  A
 committer will then review the patch and assume the legal issues
 of committing it themselves.  Likely they will contact the patch
 submitter and get a confirmation that the patch can be used.

 The committers will have some guidelines on recognizing when it is
 reasonable to accept a patch.  It should be clear when something
 has little basis for being deemed intellectual property, versus a
 major change with advanced algorithms.

In your note, you mentioned:

   I suppose that I could assign them those rights, but personally I
   find that idea repugnant since I don't believe in intellectual
   property grin.  (Hmm.  If I put my stuff in the public domain, how
   would that play in?)

Repugnancy aside :^) your second comment is on the mark.  It isn't so 
much that you need to assign and lose ownership.  Rather, the 
committer needs to ensure that they aren't violating your rights.

We'll probably work up some boilerplate such as, I'm going to commit 
your patch to Zope.  It's going to be available under the ZPL and the 
joint ownership model of the Zope Contributor Agreement.  Please respond 
agreeing that you understand the ZPL, the joint ownership model, and 
allow this contribution under these terms.

How does that sound?

--Paul

R. David Murray wrote:

 On Thu, 20 Sep 2001, Paul Everitt wrote:
 
So, let's begin what I'm sure will be a lively and illuminating
discussion. :^)

 
 First, would it be possible to put up a copy of the Contributor
 Agreement in html format?  If you feel the only legal version for
 signing is the PDF one fine, but it would be a lot easier for people
 to check it out if there is an html version to read.
 
 Second, I suppose you should be aware of my biases before reading
 anything more.  I don't believe in intellectual property, either
 copyright or patent.  On the other hand, they are currently the
 law of the land; and, within what seems to me to be fair use kinds
 of standards, I try to respect copyrights while encouraging people
 to use vehicles that make use of as few of the restrictions imposed
 by copyrights and patents as possible.  (You will guess that I am
 *not* a fan of the GPL, though I consider it far superior to a
 traditional copyright grin.) Also, I am not a lawyer and don't
 pretend to be very up on the subtleties of copyright law, so my
 concern may turn out to be naive.
 
 I very much like the intent stated in the Introduction, that
 of getting maximal rights into the hands of both the contributors
 and Zope Corporation to do things in the future with the code
 without having to get an endless set of sign-offs.
 
 However, I have a concern about the Agreement that isn't covered
 in the Introduction or the FAQ.  I'm worried that the Agreement
 may exclude us from some of the benefits of the bazaar model of
 open source development.
 
 My key concern is summed up in this statement from the Introduction:
 
   Essentially, a committer signs an agreement stating that all
code that the committer submits has been created by her.
 
 The actual agreement does *not* say this, but essentially it does
 require it, since the things the committer has to swear to in
 submitting the code are very difficult to swear to unless he or
 she is the author of the code.
 
 Now, I have only contributed small amounts of code to Open Source
 projects so far.  But I'm sure there are a lot more people out there
 who have only contributed small amounts than those who have contributed
 whole modules, and that there are even fewer people who do so much
 work that jumping through these kinds of legal hoops, and agreeing to
 a certain amount of liability, is worth while.  In the cases where
 I have

Re: [Zope-dev] Vulnerability in Zope

2001-09-23 Thread Paul Everitt


Do others consider this a vulnerability?  While it reveals more 
information than people might want, I'm curious about scenarios under 
which it could be exploited.

If any of you know of something *specific*, meaning it's a genuinely 
exploitable vulnerability, please email me or Brian Lloyd 
([EMAIL PROTECTED]) directly, rather than explain to the world how to do it.

--Paul

ALife wrote:

 Found vulnerability: retrieve a full path to local files in Zope.
 
 ---[ Example 1 (Linux):
 
 telnet www.zope.org 80
 
 PROPFIND / HTTP/1.0
 
 F
 G
 H
 J
 K
 L
 HTTP/1.0 500 Internal Server Error
 Server: Zope/Zope 2.3.2 (source release, python 1.5.2, linux2) ZServer/1.1b1
 Date: Mon, 10 Sep 2001 15:38:59 GMT
 Content-Length: 7058
 Ms-Author-Via: DAV
 Bobo-Exception-File: /usr/local/base/Zope-2.3.2-modified/lib/python/OFS/Property
 Sheets.py
 Bobo-Exception-Type: TypeError
 Content-Length: 7058
 Ms-Author-Via: DAV
 Bobo-Exception-File: /usr/local/base/Zope-2.3.2-modified/lib/python/OFS/Property
 Sheets.py
 Bobo-Exception-Type: TypeError
 Content-Type: text/html
 Bobo-Exception-Value: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//
 EN http://www.w3.org/TR/REC-html40/loose.dtd; HTML  HEAD  TITLEWelcome
 to Zope.org/TITLE   link rel=stylesheet href=http://www.zope.org/zope_css;
  type=text/css   /HEAD   BODY B
 Bobo-Exception-Line: 369
 
 
 ...
 
 
  !--
  Traceback (innermost last):
   File /usr/local/base/Zope-2.3.2-modified/l
 ib/python/ZPublisher/Publish.py, line 223, in publish_module
   File /usr/local/ba
 se/Zope-2.3.2-modified/lib/python/ZPublisher/Publish.py, line 187, in publish
F
 ile /usr/local/base/Zope-2.3.2-modified/lib/python/Zope/__init__.py, line 221, i
 n zpublisher_exception_hook
(Object: ApplicationDefaultPermissions)
 File /us
 r/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/Publish.py, line 171, in
 publish
  File /usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/mapply.p
 y, line 160, in mapply
   (Object: PROPFIND)
   File /usr/local/base/Zope-2.3.2-mo
 dified/lib/python/ZPublisher/Publish.py, line 112, in call_object
  (Object: PR
 OPFIND)
  File /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/Resource.py,
  line 222, in PROPFIND
   (Object: ApplicationDefaultPermissions)
File /usr/loc
 al/base/Zope-2.3.2-modified/lib/python/webdav/davcmds.py, line 219, in apply
   Fi
 le /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/davcmds.py, line 219, i
 n apply
  File /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/davcmds.py,
 line 219, in apply
 File /usr/local/base/Zope-2.3.2-modified/lib/python/webdav/d
 avcmds.py, line 219, in apply
File /usr/local/base/Zope-2.3.2-modified/lib/pyth
 on/webdav/davcmds.py, line 175, in apply
   File /usr/local/base/Zope-2.3.2-modifi
 ed/lib/python/OFS/PropertySheets.py, line 369, in dav__allprop
   (Object: Virtu
 al)
TypeError: (see above)
 
  --
 Host has closed connection.
 
 ---[ Example 2 (Linux):
 telnet www.zope.com 80
 
  / HTTP/1.0
 or NOTREALCOMMAND / HTTP/1.0
 
 
 HTTP/1.0 404 Not Found
 Server: Zope/Zope 2.3.2 (source release, python 1.5.2, linux2) ZServer/1.1b1
 Date: Fri, 21 Sep 2001 12:51:48 GMT
 Bobo-Exception-File: /usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/H
 TTPResponse.py
 Content-Type: text/html
 Bobo-Exception-Type: NotFound
 Bobo-Exception-Value: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//
 EN http://www.w3.org/TR/REC-html40/loose.dtd; HTML  HEAD  TITLEWelcome
 to Zope.org/TITLE   link rel=stylesheet href=http://www.zope.org/zope_css;
  type=text/css   /HEAD   BODY B
 Content-Length: 5845
 Bobo-Exception-Line: 547
 
  ... 
 
  !--
  Traceback (innermost last):
   File /
 usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher/Publish.py, line 223, i
 n publish_module
   File /usr/local/base/Zope-2.3.2-modified/lib/python/ZPublisher
 /Publish.py, line 187, in publish
File /usr/local/base/Zope-2.3.2-modified/lib/
 python/Zope/__init__.py, line 221, in zpublisher_exception_hook

Re: [Zope-dev] questions about writing a DA

2001-09-23 Thread Paul Everitt


I just took a look at ODBC Socket Server, which I had never seen before. 
  Pretty interesting!  Here's some comments.

1) It looks like socket server opens a new socket for processing every 
request.  In this respect, it goes against one of the benefits of 
database adapters, which keep a persistent connection.

2) Architecturally, socket server is very similar to web services.  See 
the fishbowl proposal at dev.zope.org for more info.  Thus, the approach 
that Zope would do for web services might have some similarity to what 
you'd like to do.  Alternatively, take a look at the adapter for 
Ultraseek search engine at 
http://www.zope.org/Members/brianh/UltraseekDA.  It gives a model that 
might be useful to you.

3) Zope's approach of having separate objects that handle database 
connections provide the benefit that regular objects can't just fire up 
socket connections.  You want a model that helps prevent all of Zope's 
threads from being stuck waiting on responses to socket requests.

4) SQL Methods provide some useful and important machinery for your 
socket server approach.  First, I think you want site developers to 
think your thing is exactly the same as a regular SQL Method.  Also:

   - You likely want to keep the arguments list approach, to
   prevent people from inserting malicious data into the SQL requests.

   - Even more than with current database adapters, you want to
   retain the caching feature in SQL Methods.

   - Shoving the results into the Recordset code is something
   you might want to keep.

   - Etc.

Good luck, this looks like a useful project!

--Paul

StevenLee wrote:

 hi,all
 
 I have got several questions here,and maybe you can give me some advice.
 
 What I am trying to do  is write a product which can communicate with ODBC Socket 
Server,
 a win32 server application that allow applications to have access to Data Sources 
managed by Windows ODBC 
 DataSource Administrator. And now a class written in python can communicate with 
ODBC Socket Server.
 BTW,the class mentioned above  handles the connection to the server,sending SQL 
statement,and Receiving results.
 
 As far as I know, in Zope,to access Data Sources,one must create a Database 
connection and  
 ZSQLMethods associated with it to get the results. (but I have doubt about this,
 IMHO,there must be some other way to do so,but what is it.).
 
 Now,I am rather confused about how to solve the problem. 
 First,is what I need to write a DA? or just a common product?
 Second,if it's a DA, how can I use the existing class? I have read the article named 
how to write a DA in the how-tos,but it is quite abstract to me. 
 Third,where can I find more about the DataBase Connection and ZSQLMethod ? 
especially on how they work together to access databases.
 
 OK,I am not sure whether I have made me understood, in fact,I am not quite clear 
myself. if you have any questions about that,I will reply ASAP.
 
 thanks for your great patience,I will be grateful if you can give me some advice.
 thank you!
 
 Best Wishes
 
 yours sincerely
 Steven Lee  
 f?
 
?j)e?Y+?m?^8.??+-???:)y?6?+(7))(7)l1.?r??^?^vX?+-?:)z???f?X?)?q+-?:)z???f?X?)??pe==
 




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



Re: [Zope-dev] DISCUSS: Community checkins for CVS

2001-09-21 Thread Paul Everitt


This is a good point, and one that we need to settle on pretty quickly. 
  The language is an artifact from the Mozilla contributor form, which 
served as the starting point for this.  We intended to follow it, but 
with the advent of the joint ownership idea (which came late in the 
process), we might want to revisit it.

Either way, I'll get an answer for you, thanks!

--Paul

Morten W. Petersen wrote:

 On Thu, 20 Sep 2001, Paul Everitt wrote:
 
 
So, let's begin what I'm sure will be a lively and illuminating
discussion. :^)

 
 First man out?  :-)
 
 Will a ZPL-ish license [1] be accepted (declared, ref. paragraph
 4 of the Zope Contributor Agreement) by the Zope Corporation?
 
 [1] http://www.thingamy.org/tpl
 
 -Morten
 
 




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



Re: [Zope-dev] DISCUSS: Community checkins for CVS

2001-09-21 Thread Paul Everitt


I'll reply in more depth later (on the way out for my b-day dinner), but 
in short: I think the issue of overhead on patches is something for us 
to consider.  We won't do something that breaks the integrity of the 
code base, but there might be ample discussion directions.  Thanks!

--Paul

Dieter Maurer wrote:

 R. David Murray writes:
   ...
   So, the many small contributions that make a bazaar software project
   tend rapidly toward high quality, which is one of the things I got
   the impression you are trying to achieve by opening up the CVS
   repository, may not materialize under this Agreement.  We'll have
   just about the same situation we have now, except that there will
   be more committers and therefore, one hopes, an increase in the
   pace of (controlled) change.  An improvement, yes, but can we do
   even better?
 I think (and indeed I really hope) that your anxiety is not founded.
 
   The Zope Contribution Initiative took Python as model.
   There, you have beside contributors a bug tracking system
   where problems can be reported and patches posted to.
 
   I do not know the details of Python development process,
   especially the legal agreements behind it.
   But somehow, it seems to work...
 
 
 
 Dieter
 




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



Re: [Zope-dev] ZPL and GPL

2001-06-27 Thread Paul Everitt


With great trepidation, I add a post to this thread.  As Barry has 
mentioned, this has all been discussed a LOT.  I'll try to summarize and 
clarify a few points:

1) I wanted to specifically address something in Michael's post here. 
We fully expect people to profit from Zope, even if that means for-fee, 
intact redistributions.  They simply have to provide credit.  Others may 
have a different philosophy, but that's ours.  This is similar in some 
regards to Perl's and Apache, I believe.

2) We specifically expect to produce a packaged version of Zope.  It's 
clear that it's the only way to appeal to the mainstream market.  We 
hope others do the same.

3) Regarding other posts, our license is nearly identical to Apache's 
license, close enough legally to say it is the same.  Therefore, to say 
Zope isn't free enough is to say Apache isn't free enough.  Anybody that 
says that loses a fair amount of credibility, at least with me.  Apache 
is an example of a crossover success (open and commercial) that I think 
provides a fantastic role model.

4) Any changes in the license are likely to be more in the direction of 
an Apache-style license.

No approach pleases everyone, unfortunately.  We do the best we can.

--Paul

Michael R. Bernstein wrote:

 On 26 Jun 2001 10:29:39 +1000, Anthony Baxter wrote:
 
Michael R. Bernstein wrote

Unless I've misunderstood something (which is certainly possible), DC
doesn't seem to have anything to lose by switching from a BSD style
license to the GPL (or a GPL style license with an additional optional
attribution clause), and quite a bit to gain.

They will probably lose developer mindshare. Given how important 
this is to Zope's growth (and to DC's growth, as a result), this 
is far far more important than the karma from switching to the 
far less flexible GPL

 
 You're right. I hadn't considered that the ZPL needs to be 'proprietary
 compatible' so far as add-on products are concerned. perhaps the LGPL
 would suffice, as that would permit creating proprietary Zope products.
 But I won't be entirely happy if the ZPL permits proprietary third-party
 redistributions of Zope itself.
 
 
Your argument seems to be that DC would want to control other companies
ability to make distributions derived from Zope - unless they've been 
hiding this nefarious plan from the community, this doesn't seem to
be an objective for them.

 
 Heh. I guess I shouldn't have stuck that in there. An argument I've
 occasionally heard for BSD-style licenses is that the original (usually
 corporate) author wants to be able to make proprietary releases based on
 other peoples contributions. The argument for NPL-style licenses is that
 they (the original author) want to be the *only* one with such a
 privileged position. DC has never indicated that either of these was
 important to them.
 
 
As far as a contributor to Zope wanting to keep their work free, then
if the ZPL is GPL compatible, they can make their components GPLd.

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

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



Re: [Zope-dev] ZPL and GPL

2001-06-27 Thread Paul Everitt


I'd like to add a quick clarification, then I'll reply more later. 
Frederico brought up a good point that indicated I wasn't clear.  It is 
a *desire* of ours to be GPL-compatible.  Not a requirement, as it can 
be awfully tricky, complicated, and time-consuming to get there.  But 
we've told people that we're intending to give it a shot.

--Paul

Federico Di Gregorio wrote:

 hi,
 
 i wanted to draw myself from this thread before annoying the whole list,
 so i'll take paul mail as an excuse to write some final comments.
 
 On 27 Jun 2001 09:06:16 -0400, Paul Everitt wrote:
 
1) I wanted to specifically address something in Michael's post here. 
We fully expect people to profit from Zope, even if that means for-fee, 
intact redistributions.  They simply have to provide credit.  Others may 
have a different philosophy, but that's ours.  This is similar in some 
regards to Perl's and Apache, I believe.

 
 i think that nobody (ever gpl-oriented people like me) have anything
 against making profit from free software. profit means more time and
 resources to write even better software, profit is *good*. 
 
 
2) We specifically expect to produce a packaged version of Zope.  It's 
clear that it's the only way to appeal to the mainstream market.  We 
hope others do the same.

 
 that's a business strategy. good or bad has nothing to do with
 licensing. i wish you all possible luck with a packaged version of zope.
 i'll even buy one if includes a well-written well-printed manual about
 zope internals... ;-)
 
 
3) Regarding other posts, our license is nearly identical to Apache's 
license, close enough legally to say it is the same.  Therefore, to say 
Zope isn't free enough is to say Apache isn't free enough.  Anybody that 
says that loses a fair amount of credibility, at least with me.  Apache 
is an example of a crossover success (open and commercial) that I think 
provides a fantastic role model.

 
 again, i agree. apache. *is* free. zope *is* free. end of the argument.
 
 
4) Any changes in the license are likely to be more in the direction of 
an Apache-style license.

 
 let me try to explain why this is bad and a gpl-compatible license will
 be better. a lot of people, like me, wants other use their work, even
 for making money. but we want something back. this is why the gpl is
 good. if you use my work you can:
 
 1/ release your sources under a gpl compatible license; or
 
 2/ give me some money for an alternate license: this is good because
 i'll use the money to write even more software (see it as an exchange,
 you can keep your sources propietary but you finance someone for writing
 free code that will be made available to the community.)
 
 the main problem with licenses like tha apache one is that they allow
 people to use public, free code without giving *anything* back.
 
 with its current license dc is forcing *me* to release under a license
 that i don't like (ZPL) because if i release my software unsed the gpl
 nobody will be able to redistribute it. this will make more and more
 people like me abandon zope first or later (i hope later). the current
 license surely does not push away companies that don't want to open
 their sources but what good come from that? nothing. no software for us
 and no money for dc.
 
 what if the zpl would be gpl-compatible? the situation will be reversed.
 a lot of people will continue to write and distribute zope products and
 the occasional company not wanting to release will pay dc and other
 developers for an alternate license. this will make *everybody* happy.
 
 as i said before the *worst* case for zope going gpl-compatible is the
 no-harm situation, while going apache-like is a little harm to some
 entusiast developers and surely no good.
 
 i finished. no more mail on this argument, and sorry for my bad english,
 i wrote this one in an hurry...
 
 federico
 
 




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



Re: [Zope-dev] [Announce] API Documentation Fishbowl Project

2001-06-06 Thread Paul Everitt


Hmm, I'm surprised that 2 days has passed with no comment from zope-dev
and no comments in the Wiki.  I hear constant complaints about lack of a
polished API.  I expected this post to generate lots of interest.

What say ye, zope-dev?  Is this something we should be doing, or would
you prefer a different documentation activity to have priority?  Is the
proposed solution agreeable?

For all of you that have chimed in about the API, here's a chance for
you to get involved and help make it a strong effort.  Help!! :^)

--Paul

Amos Latteier wrote:
 
 Fellow Zopistas,
 
 Mike Pelletier and I are working on a project to improve Zope's API
 documentation. Details are now publicly available in the fishbowl.
 (Actually it's been public for a while, but this is the first
 announcement of the project.)
 
   http://dev.zope.org/Wikis/DevSite/Projects/APIDocs
 
 I encourage you to check it out and leave your comments, criticisms, and
 suggestions.
 
 This project aims to improve the life of Zope developers, so please help
 us make sure we're not off base. For the project to succeed it must meet
 *your* needs.
 
 Thanks!
 
 -Amos
 
 --
 Amos Latteier mailto:[EMAIL PROTECTED]
 Digital Creations http://www.digicool.com
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

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



Re: [Zope-dev] ANNOUNCE: Zope 2.4.0 alpha 1 released

2001-06-01 Thread Paul Everitt


As one more example, Zope.org is currently at 4.8 Gb on FileStorage.

--Paul

R. David Murray wrote:
 
 On Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote:
  My impression is that FileStorage implements a 32-bit id-type-thingy
  somewhere (look at ZODB docs, I think there is something about this
  somewhere), which limits it (in addition to the Linux kernel ext2 fs limit),
  to  2GB.  With 7.5 GB, I'd use a more advanced storage like the new - well,
  not quite released ;) - Berkeley (libdb3 based) storages, though I haven't
  tried anything like that myself...
 
 FileStorage does *not* have a 2GB limit.  The only 2GB limit is the old
 Linux filesystem limit.  I know this, because I've had 2GB Data.fs
 files on FreeBSD.
 
 --RDM
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

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



Re: [Zope-dev] ANNOUNCE: Zope 2.4.0 alpha 1 released

2001-06-01 Thread Paul Everitt



Lalo Martins wrote:
 By hoping that EC will go away soon, I assume they mean the
 PythonLabs folks are working on fixing this for once in Python
 itself. Right?

That is correct.  The point is, ExtensionClass machinery will go away
but the functionality would remain, if Python changes in the future to
make it unnecessary.

--Paul

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



Re: [Zope-dev] License issues

2000-11-15 Thread Paul Everitt


Some quick points on this.

First, feel free to talk on this list about ways that Zope
developers can license their stuff.  It's a constructive
discussion, and since I'm not a Zope developer, I can ignore
it. :^)

Second, regarding the licensing of Zope itself, ChrisP is
right that I'm the guy on that.  Or more specifically, Hadar
Pedhazur (our board chairman) and I run the zope-license
email alias.  He and I had previously decided that, after
the round closed, we'd take a fresh look at our licensing
strategy.

Basically, we'd like to get out of the business of having
our own license, and we're open to the idea of a license
that is more GPL-friendly, in the spirit of Apache, Python,
etc.

Thus, continue discussing what you need to do your jobs and
give us some time to hash out a proposal.  Thanks!

--Paul

On 14 Nov 2000 09:29:11 -0800
 Simon Michael [EMAIL PROTECTED] wrote:
 Juan, thanks for shining some light towards this murky
 area. Maybe
 ZWiki and other zope products need to be LGPL or
 dual-licensed, maybe
 the zope license can use some refinement. I for one won't
 know without
 seeing some enlightened discussion of the issue.
 
 This stuff is unsexy but important.
 
 Best regards,
 -Simon
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 


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




Re: [Zope-dev] Do I really understanding caching?

2000-09-23 Thread Paul Everitt

Andy McKay wrote:
  What problem are you trying to solve -- response time, memory usage,
  disk usage?
 
 All of the above :)

Describe some of the symptoms back on the list and let's talk about it
there.  For instance, you can trade RAM for performance by adjusting
knobs on the catalog.

--Paul

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




Re: [Zope-dev] HiperDOM xmlc

2000-09-17 Thread Paul Everitt

[EMAIL PROTECTED] wrote:
 BTW, please don't call the solution "xHTML Template"; it's not
 xHTML, it's generic XML - it can easily be used for RSS or WML
 or MathML or NewsML for example.

While it *can* be used that way (just as DTML can be used to send mail
messages), that's not the real intent of this proposal nor is that the
real audience.  Our proposal it focused on letting HTML-oriented people
with HTML-oriented tools create compliant stuff for the presentation
job.

At the same time, the markup must be compliant XML or it won't work. 
The W3C has a term for the intersection of these two spaces: XHTML. :^)

Finally, I think the notion of XHTML stylesheets (or templates) could
really catch flight beyond Zope, which would be good for everybody.

--Paul

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




Re: [Zope-dev] HiperDOM xmlc

2000-09-15 Thread Paul Everitt


I'm surprised that no one responded to this.  (Or maybe people did and
our continual email server problems have lost it.)

I'd like to congratulate Hiperlogica, because they have (ding ding ding)
the _right answer_! :^)

Seriously, we at Digital Creations have been quietly formulating a
proposal on this since Amos put up the template proposal in
dev.zope.org.  I floated some trial balloons at EuroZope and it's clear
there's some consensus.

Our "XHTML Templates Proposal" is at:

  http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal

Since Wiki is having a tough time on the list here lately, I'll post the
text in a message in just a second.

To summarize, we at DC at least think that Hiperglocia is on to the
right thing and we'd like to indicate support for that direction.

--Paul

[EMAIL PROTECTED] wrote:
 
 We (I and Hiperlogica, a company I consult with) have been
 developing a template renderer with similar intent to xmlc
 (be based on XML/DOM, allow the template to be previewed and
 edited using tools not aware of the format, such as xHTML
 editors, and enforce presentation/logic separation).
 
 As the project is somewhat on hold while we have more pressing
 issues, I decided to share the current (rather kludgy)
 prototype with the community. It is at
 http://www.zope.org/Members/lalo/HiperDOM/
 
 On Mon, Sep 11, 2000 at 02:06:08PM +, Jason Spisak wrote:
  Zope Devers,
 
  THis is going to seem strange coming from someone who hasn't been on the
  list in a long time, but I was at the Linux Expo in San Jose, and sat in on
  a Web app talk.  Lutris was in charge of the panel, and they talked about
  xmlc.  I went to their booth and asked about it. I think it could be the
  best way to get hard-core python people to jump on zope's band-wagon, and
  stop the dtml frowning.
 
  If you who are in the know about zope have time, please read a quick bit on
  what it is.
 
  http://xmlc.enhydra.org
 
  Especially the tutorial:
 
  http://staff.plugged.net.au/dwood/xmlc/index.html
 
  Is there any obvious reason why Zope wouldn't benefit tremendously from
  this design and programming separation and pure python boost?
 
 []s,
|alo
+
 --
   Hack and Roll  ( http://www.hackandroll.org )
 News for, uh, whatever it is that we are.
 
 http://zope.gf.com.br/lalo   mailto:[EMAIL PROTECTED]
  pgp key: http://zope.gf.com.br/lalo/pessoal/pgp
 
 Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

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




[Zope-dev] DISCUSS: XHTML Templates proposal

2000-09-15 Thread Paul Everitt


Howdy folks.  As advertised in my last email, below is our Fishbowl
Proposal on a new template architecture.  Some notes:

1) This mostly replaces DTML.  As mentioned, the goal isn't necessarily
to get DTML removed from Zope.  Rather, most of the audience will see it
little or none of the time.

2) This proposal has gotten more internal DC scrutiny from a
requirements perspective than anything we've done.  The proposal has
been rewritten four times.

3) The original version of this forced the connection between
reinventing the data tier (documents) and the presentation tier
(templates/pages/stylesheets).  We eventually found the way to decouple
the connection, but we still need to write a documents proposal.

4) What this really, really needs right now is extensive user
documentation with screenshots written *before* the software.  This is
where we got stuck.  Docs are the fastest way to confront the myriad of
usage details.

5) Our proposal is a little more ambitious than HiperDOM (we have a
concept of "components" that are hinted to but not explained).  But for
now, HiperDOM is a good basis for exploring XHTML Templates.

6) I'm still not convinced template is the right word.  Unfortunately
I'm less convinced at any alternatives.  Whatever is chosen, it must
feel "normal" to the vast majority of the audience.

Cheers!

--Paul

XHTML Template Architecture

  Zope should increase usability and promote separation of tiers by
  moving to a presentation and data architecture.  Site Designers will
  author and round-trip presentation objects in familiar tools.
  Combined with the Document Architecture, this proposal establishes
  the fundamental content and presentation architecture for Zope.

Note on status

  The great folks at Hiperglocia have already produced something quite 
  similar to what is discussed here.  Their Zope product is called 
  "HiperDOM", http://www.zope.org/Members/lalo/HiperDOM/.

Note On Jargon

  The choice of term for the presentation object has been contentious.
  Right now the list of choices include: template, view, page, or
  stylesheet.  This proposal doesn't make the decision on the jargon.
  Rather, the tier is usually refered to as the presentation.  When a
  choice has to be made, such as the Architecture section, Template is
  used as the temporary choice.

Problem

  Zope currently has a model of DTML Documents and DTML Methods as the
  basic data and presentation tiers.  However, this model is
  confusing, doesn't promote separation of tiers, and doesn't work
  with popular web design/authoring tools.

  For the presentation tier, Site Designers are faced with an idiom in
  which well-formed HTML is split between two "files"
  (standard_html_header and standard_html_footer).  Also, the
  presentation mockups are "taken away" by programmers who insert a
  bunch of alien tags that don't present anything on the screen of the
  web design tool.

  Worse, DTML is fundamentally impossible to edit directly by classic
  tools due to the "source vs. rendered" issue.  That is, when a Site
  Designer wants to edit a piece of DTML, they will get the *rendered*
  version of the DTML for editing, where all the DTML tags are
  expanded into HTML.

  In summary, there is a tremendous usability issue, both conceptual
  and in practice.

  There are additional problems:

o DTML is considered a "proprietary" language

o Data needs to have different presentations used under different
conditions

o Consulting practices need a way for customers to start seeing
screen results immediately without having the programmer "steal"
the templates by converting them to something alien

Goals

  The goals of the Presentation Architecture are:

o Clear separation of presentation, data, and logic with clear
concepts in Zope for these tiers and audiences

o Increase usability by allowing round trip presentation with
common tools and familiar concepts

o Allow those presentation tools to work by having well-formed
markup (e.g. no separation into header and footer)

o Supplant "proprietary" markup language (DTML) in presentation
tier by leveraging standards (XHTML) (Note: "eliminate" isn't the
target as it might not be feasible in 100% of the cases)

o Match the appropriate level of capability currently in DTML
usage

o Simple presentation reuse within reach of standard tools

Solution

  Zope should move to an architecture with clear separation of
  presentation, data, and logic, with clear concepts in Zope for these
  tiers and audiences.

  The presentation tier will get a tremendous usability increase by
  allowing round trip presentation with common tools.  This also
  ensures that Site Designers finish with the same stuff they started
  with, meaning the programmers don't come in and cast their work into
  "code".

  The architecture should make sure those presentation tools are
  effective by having well-formed markup (e.g. no 

Re: [Zope-dev] DISCUSS: XHTML Templates proposal

2000-09-15 Thread Paul Everitt


[EMAIL PROTECTED] wrote:
 IMHO, view, page, and stylesheet don't make the grade due to
 conflicts/confusion with unrelated technologies (e.g. MVC, "server pages",
 CSS, etc.).

On the other hand, reading the "What is styles?" material at:

  http://www.w3.org/Style/

...makes me think that the goals of the people using these things (site
designers) are the same as the goals of the audience described for
stylesheets.  That is, these are things that control the presentation.

--Paul

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




[Zope-dev] PLEA: Provide feedback on OracleStorage

2000-09-03 Thread Paul Everitt


Hello sports fans.  Last week we released a beta of OracleStorage. 
There was a pretty strong drumbeat in Zopeland for us to go ahead and
get this out.  We spent some extra time on the installation process and
instructions to make sure it was straightforward to use.

We at DC would like to get OracleStorage hardened as fast as possible. 
Thus, I have a serious of requests:

a. If you are interested in it, please download it this week and give it
a shot.

b. If you downloaded it, please send me a note and tell me so.

c. If you find any bugs with it, please file something in the
Collector.  We'll make sure there's a keyword for OracleStorage.

d. If you have a general question, request, or discussion, start a
thread here in zope-dev.

My indebtedness goes out to anybody that can help us on this.  Thanks!

--Paul

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