Re: [Zope-dev] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Wichert Akkerman
Previously Dan Korostelev wrote:
 2009/2/24 Shane Hathaway sh...@hathawaymix.org:
  Log message for revision 97183:
   New library for OpenID auth in Zope 3
 
 
  Changed:
   A   zope.app.openidconsumer/
 
 Wow, that's great! Finally an OpenID auth plugin is being developed!

plone.openid has been out since August 2007, so it's hardly the first
OpenID auth implementation for Zope..

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Dan Korostelev
 Wow, that's great! Finally an OpenID auth plugin is being developed!

 plone.openid has been out since August 2007, so it's hardly the first
 OpenID auth implementation for Zope..

Well, yeah, but plone.openid uses Zope2 and Plone PAS while this is a
pure zope3 solution. However I'd like to see parts that are neither
zmi-specific nor plone-specific to be refactored to a separate
package. The ZopeStore from plone.openid, for example :-)

-- 
WBR, Dan Korostelev
___
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] z3c.jsonrpc relase

2009-02-24 Thread Jim Washington
Roger Ineichen wrote:

 does someone have a good idea how we can handle an
 Unauthorized error with JSON-RPC? Should we use an error
 view concept and include a JavaScript method which can handle
 a special error code/message from the server and show a kind
 if login form?
 
 Any hints or does somebody know a framework which supports such 
 an implementation?

Hi Roger

Here's a hint I've been looking at.  Maybe it will give you some ideas.

http://ajaxpatterns.org/Direct_Login


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


Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype

2009-02-24 Thread Benji York
On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev nad...@gmail.com wrote:
 2009/2/24 Baiju M mba...@zeomega.net:
 Hi Dan,

 On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev nad...@gmail.com wrote:
 Log message for revision 97207:
  Create infrastructure for z3c.mimetype

 Changed:
  A   z3c.mimetype/

 I thought of sharing this with you, may be useful.  I have got one tip from
 Jim for creating a new project area:
 http://mail.zope.org/pipermail/zope3-dev/2006-October/020701.html

 Heh, nice trick with `z` :) Thank you.

A slight refinement:

svn mkdir path-to-repo/new-project{,trunk,tags,branches}

Using the `z` trick, that would be:

svn mkdir `z`/new-project{,trunk,tags,branches}
-- 
Benji York
Senior Software Engineer
Zope Corporation
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype

2009-02-24 Thread Dan Korostelev
2009/2/24 Benji York be...@zope.com:
 On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev nad...@gmail.com wrote:
 2009/2/24 Baiju M mba...@zeomega.net:
 Hi Dan,

 On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev nad...@gmail.com wrote:
 Log message for revision 97207:
  Create infrastructure for z3c.mimetype

 Changed:
  A   z3c.mimetype/

 I thought of sharing this with you, may be useful.  I have got one tip from
 Jim for creating a new project area:
 http://mail.zope.org/pipermail/zope3-dev/2006-October/020701.html

 Heh, nice trick with `z` :) Thank you.

 A slight refinement:

    svn mkdir path-to-repo/new-project{,trunk,tags,branches}

 Using the `z` trick, that would be:

    svn mkdir `z`/new-project{,trunk,tags,branches}

Thanks! BTW, there tips are probably useful enough to be included to
zope3docs' development section. :)

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Shane Hathaway wrote:
 I've been working on the dependencies to and from zope.publisher. 
 Refining the dependencies should make it easier to integrate 
 zope.pipeline when it's ready.
 
 I've noticed that nearly all packages that depend on zope.publisher 
 depend only on a few pieces of it:
 
- zope.publisher.interfaces
 
- zope.publisher.browser.Browser{View|Page}
 
- zope.publisher.browser.TestRequest
 
 One simple, low-risk refactoring I would like to do is move 
 zope.publisher.interfaces into its own package, make zope.publisher a 
 namespace package, and make zope.publisher depend on 
 zope.publisher.interfaces.  The __init__.py in zope.publisher is already 
 empty, so I expect the namespace conversion to be safe.  Then I'd like 
 to refine the dependency list of various packages that only require 
 zope.publisher.interfaces.  Any objections?

+1.

 It is less clear what we should do with BrowserView and BrowserPage. 
 They depend on zope.location, unlike the rest of zope.publisher, so they 
 don't really fit there.  Perhaps those two belong in a new package, 
 zope.publisher.browserbase.  There is also the tiny new zope.browser 
 package.  Would it make sense to move them there?  (It's hard to tell 
 what the intent of the new package is.)  I'd love to hear other suggestions.

zope.browser is supposed to be a zero-dependency spot for commonly-used
interfaces:

  This package provides shared zope browser components without other
  dependencies.

So I wouldn't move anything depending on zope.location into that
package.  Your new package idea sounds better.

 As for TestRequest, I could update the setup.py of various packages that 
 currently depend on zope.publisher just for TestRequest.  I would make 
 zope.publisher a test-only requirement.

Frankly, any code using a testing stub which is that heavyweight needs
to be refactored.


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

iD8DBQFJpAOY+gerLs4ltQ4RAjp/AJ9sbBrxvOrWkjFuypP7/16n75uUkwCgvtZW
3J0s+vDo0p1nxkxhtrFbS/A=
=FUZq
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype

2009-02-24 Thread Zvezdan Petkovic

On Feb 24, 2009, at 8:53 AM, Dan Korostelev wrote:
 2009/2/24 Benji York:
 On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev wrote:
 Heh, nice trick with `z` :) Thank you.

 A slight refinement:

svn mkdir path-to-repo/new-project{,trunk,tags,branches}

 Using the `z` trick, that would be:

svn mkdir `z`/new-project{,trunk,tags,branches}

 Thanks! BTW, there tips are probably useful enough to be included to
 zope3docs' development section. :)

Or even one character shorter, (plus no need to create a script, put  
it in the path and make it executable)
:-)

svn mkdir $Z/new-project{,trunk,tags,branches}

where Z is an environment variable in your .profile (or .bash_profile)

Z=svn+ssh://svn.zope.org/repos/main
export Z

or  .login for C shell users

setenv Z svn+ssh://svn.zope.org/repos/main

Do we need to put a disclaimer that for the shortcut shown above the  
shell needs to support brace expansion -- the output of ``set -o``  
should have ``braceexpand on``.

Most of the modern Bourne-derived shells do have it and it's on by  
default.  The C shell has always had it AFAIK.  A user could switch it  
off in both shell kinds.

I guess that would be too much detail.
:-)

___
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] Review of zc.dict tlotze-blist branch

2009-02-24 Thread Gary Poster
[Thomas asked me to review his zc.dict branch a while ago.]

Hi Thomas.  Thank you for this work.  It looks great.  I do have  
several comments below (from an abbreviated diff against the current  
trunk).

  Index: buildout.cfg
  ===
  --- buildout.cfg (.../trunk) (revision 97211)
  +++ buildout.cfg (.../branches/tlotze-blist) (revision 97211)
  @@ -2,11 +2,10 @@
   develop = .
   parts = test py
 
  -find-links = http://download.zope.org/distribution/
  -
   [test]
   recipe = zc.recipe.testrunner
  -eggs = zc.dict
  +eggs = zc.dict [generations]
  +defaults = [-v, -c]

I don't think the generations code should be required, and (since you  
used extras_require) neither do you.  Therefore I'd prefer it if the  
main tests also didn't depend on that code.  The way I've done this  
with other packages (e.g. 
http://svn.zope.org/zc.async/trunk/buildout.cfg?view=auto) 
  is to have multiple test sections (with different names).  The  
downside is that then, to run all possible tests, you have to run more  
than one command.  The upside is that arguably the most important  
configuration--the base one--is truly tested.

 
   [py]
   recipe = zc.recipe.egg
  Index: CHANGES.txt
  ===
  --- CHANGES.txt  (.../trunk) (revision 97211)
  +++ CHANGES.txt  (.../branches/tlotze-blist) (revision 97211)
  @@ -1,3 +1,8 @@
  +1.3 (unreleased)
  +
  +
  +* changed the implementation of OrderedDict to store the order in  
buckets

I suggest adding via zc.blist or something like that.

...

  Index: src/zc/dict/configure.zcml
  ===
  --- src/zc/dict/configure.zcml   (.../trunk) (revision 0)
  +++ src/zc/dict/configure.zcml   (.../branches/tlotze-blist)  
(revision 97211)
  @@ -0,0 +1,5 @@
  +configure xmlns=http://namespaces.zope.org/zope;
  +
  +  include package=.generations /
  +
  +/configure

configure.zcml has a semantic of always include.  Because the  
generations code may not work for many people (as we've discussed  
before, and see comment in evolve test below), I'd prefer that the  
generations code have a semantic of optionally include.  Therefore,  
I suggest you rename this to generations.zcml or something like that.

...

  Index: src/zc/dict/dict.py
  ===
  --- src/zc/dict/dict.py  (.../trunk) (revision 97211)
  +++ src/zc/dict/dict.py  (.../branches/tlotze-blist) (revision 97211)

...

   def __setitem__(self, key, value):
  -delta = 1
  -if key in self._data:
  -delta = 0
  -self._data[key] = value
  -if delta:
  +if key not in self._data:
   self._order.append(key)
  -self._len.change(delta)
  +self._len.change(1)
  +self._data[key] = value

Nice improvement in readability.

 
   def updateOrder(self, order):

...

Also as mentioned before on the Zope list, until this API is  
deprecated in favor of one that encourages more granular changes, the  
change to blist only really helps the story for adding new items to an  
ordered dict.

The Plone IExplicitOrdering interface looks reasonable, and could  
really take advantage of the blist characteristics.

http://dev.plone.org/plone/browser/plone.folder/trunk/plone/folder/interfaces.py

  Index: src/zc/dict/generations/evolve1.txt
  ===
  --- src/zc/dict/generations/evolve1.txt  (.../trunk) (revision 0)
  +++ src/zc/dict/generations/evolve1.txt  (.../branches/tlotze-blist) 

...

As we discussed earlier, findObjectsMatching will miss OrderedDicts  
that are used as internal data structures.  I regard that as a primary  
use case for this package, so IMO that's important to note in the doc  
and in the Python file.

Otherwise, looks great to me.

Thank you!

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:

 I've been working on the dependencies to and from zope.publisher.
 Refining the dependencies should make it easier to integrate
 zope.pipeline when it's ready.

Can you elaborate on this a bit?

 I've noticed that nearly all packages that depend on zope.publisher
 depend only on a few pieces of it:

   - zope.publisher.interfaces

   - zope.publisher.browser.Browser{View|Page}

   - zope.publisher.browser.TestRequest


I'd like to turn this around a little bit.  Only browser-based code  
should depend on zope.publisher.  This seems like a very reasonable  
dependency.  It's like wxwindows UI code depending on wxwindows.   
Maybe the browser code should be factored out of the packages that  
depend on zoep.publisher so that only *that* code has the dependency  
and non-browser code doesn't.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote:
...
 As for TestRequest, I could update the setup.py of various packages  
 that
 currently depend on zope.publisher just for TestRequest.  I would  
 make
 zope.publisher a test-only requirement.

 Frankly, any code using a testing stub which is that heavyweight needs
 to be refactored.


There's nothing all that heavyweight about TestRequest.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] z3c.jsonrpc relase

2009-02-24 Thread Roger Ineichen
Hi Jim

 Betreff: Re: [Zope-dev] z3c.jsonrpc relase
 
 Roger Ineichen wrote:
 
  does someone have a good idea how we can handle an 
 Unauthorized error 
  with JSON-RPC? Should we use an error view concept and include a 
  JavaScript method which can handle a special error 
 code/message from 
  the server and show a kind if login form?
  
  Any hints or does somebody know a framework which supports such an 
  implementation?
 
 Hi Roger
 
 Here's a hint I've been looking at.  Maybe it will give you 
 some ideas.
 
 http://ajaxpatterns.org/Direct_Login

Thanks a lot for the hint.

Regards
Roger Ineichen
_
END OF MESSAGE
 
 - Jim Washington
 

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Stephan Richter
On Tuesday 24 February 2009, Shane Hathaway wrote:
 I've noticed that nearly all packages that depend on zope.publisher
 depend only on a few pieces of it:

    - zope.publisher.interfaces

Can you give examples?

    - zope.publisher.browser.Browser{View|Page}

    - zope.publisher.browser.TestRequest

Packages that depend on those classes usually more or less implicitly depend 
on zope.publisher. So the split might be arbitrary for this example.

 One simple, low-risk refactoring I would like to do is move
 zope.publisher.interfaces into its own package, make zope.publisher a
 namespace package, and make zope.publisher depend on
 zope.publisher.interfaces.  The __init__.py in zope.publisher is already
 empty, so I expect the namespace conversion to be safe.  Then I'd like
 to refine the dependency list of various packages that only require
 zope.publisher.interfaces.  Any objections?

I want to see some motivation, because I fail to see how this helps. 

 It is less clear what we should do with BrowserView and BrowserPage.
 They depend on zope.location, unlike the rest of zope.publisher, so they
 don't really fit there.  Perhaps those two belong in a new package,
 zope.publisher.browserbase. 

I do agree moving BrowserView and BrowserPage out of the publisher because 
they introduce the zope.location dependency.

 There is also the tiny new zope.browser 
 package.  Would it make sense to move them there?  (It's hard to tell
 what the intent of the new package is.)  I'd love to hear other
 suggestions.

I think the purpose of the package is still defining itself. I think it will 
be defined by the things that we move into it. I am very tempted to say that 
it is a good home for BrowserView and BrowserPage.

 As for TestRequest, I could update the setup.py of various packages that
 currently depend on zope.publisher just for TestRequest.  I would make
 zope.publisher a test-only requirement.

TestRequest does not add any additional dependencies to the system, so what's 
the point? It will depend on zope.publisher.browser anyways.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote:
 ...
 As for TestRequest, I could update the setup.py of various packages  
 that
 currently depend on zope.publisher just for TestRequest.  I would  
 make
 zope.publisher a test-only requirement.
 Frankly, any code using a testing stub which is that heavyweight needs
 to be refactored.
 
 
 There's nothing all that heavyweight about TestRequest.

- - It derives from BrowserRequest, which means carrying along a *lot*
  of extra implementation baggage.  Tests which use this class, rather
  than stubbing out a dummy request which provides only the API required
  by the application-under-test, will tend to grow unexpected /
  undesirable tentacles to the request implementation.

- - Using TestRequest involves pulling in all of zope.publisher, a *big*
  dependency;  Shane wants to reduce such dependencies.



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

iD8DBQFJpBxw+gerLs4ltQ4RAosKAKDNmJoShgxtFrhi3rVFYqa3H+ncVACgmGU8
TOcde0xx65K1KeIopuy3hpk=
=/+UR
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Martijn Faassen
Shane Hathaway wrote:
 Log message for revision 97183:
   New library for OpenID auth in Zope 3
   
 
 Changed:
   A   zope.app.openidconsumer/

One question: why is this in zope.app? I think there's a consensus we're 
trying to pull as much from zope.app as possible.

Is this going to provide a ZMI UI at all? If not, I'd suggest putting it 
in zope.*

Regards,

Martijn




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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Hey Shane,

+1 on separating out zope.publisher.interfaces, as it seems low-hanging 
fruit.

Shane Hathaway wrote:
 It is less clear what we should do with BrowserView and BrowserPage. 
 They depend on zope.location, unlike the rest of zope.publisher, so they 
 don't really fit there.  Perhaps those two belong in a new package, 
 zope.publisher.browserbase.  There is also the tiny new zope.browser 
 package.  Would it make sense to move them there?  (It's hard to tell 
 what the intent of the new package is.)  I'd love to hear other suggestions.

Perhaps zope.browser is the most straightforward location, especially 
given the names of the views involved. Even if zope.browser has unclear 
intent now it'll gain more clear intent from this. That said, 
zope.browser currently doesn't depend on zope.location and it would need 
to gain this as a dependency.

 As for TestRequest, I could update the setup.py of various packages that 
 currently depend on zope.publisher just for TestRequest.  I would make 
 zope.publisher a test-only requirement.

I would prefer if we could make TestRequest also go somewhere else 
(zope.browser?) instead of making zope.publisher a test-only 
requirement. While that step would be an improvement, I think the 
greater improvement would be to find a way to reduce test-only requirements.

Regards,

Martijn

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Jim Fulton wrote:
 On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
 
 I've been working on the dependencies to and from zope.publisher.
 Refining the dependencies should make it easier to integrate
 zope.pipeline when it's ready.
 
 Can you elaborate on this a bit?

He has, though perhaps not in an obvious place for you:

http://shane.willowrise.com/archives/repozublisher/

http://shane.willowrise.com/archives/redesign-of-zopepublisher/

http://shane.willowrise.com/archives/zopepipeline/

http://shane.willowrise.com/archives/limits-of-zopepipeline/

 I've noticed that nearly all packages that depend on zope.publisher
 depend only on a few pieces of it:

   - zope.publisher.interfaces

   - zope.publisher.browser.Browser{View|Page}

   - zope.publisher.browser.TestRequest
 
 
 I'd like to turn this around a little bit.  Only browser-based code  
 should depend on zope.publisher.  This seems like a very reasonable  
 dependency.  It's like wxwindows UI code depending on wxwindows.   
 Maybe the browser code should be factored out of the packages that  
 depend on zoep.publisher so that only *that* code has the dependency  
 and non-browser code doesn't.

Shane, how integrated is code that relies on the pieces in 
zope.publisher you identified into their own packages? I have the 
impression it'll be much harder to go that way than factor bits out of 
zope.publisher instead. Especially as zope.publisher contains stuff that 
Shane has no use for with zope.pipeline, and we'd still be pulling it in 
if we didn't do the refactoring.

We got two kinds of browser-based code we should distinguish between:

* ZMI code

* framework code that supports the browser

To get rid of ZMI code, a pattern that works fairly well is to refactor 
everything *else* out of the package and leave the ZMI code in its 
original location, with backwards compatibility imports in place. 
zope.app.* packages frequently can get this kind of treatment.

Other framework code that supports the browser is much like any other 
framework code. Some packages need to be aware of the browser in order 
to perform their role as framework component at all. If those packages 
can rely on *less* code that would be an improvement.

I'm not very much in favor of making these sub-packages of 
zope.publisher though, as to me a sub-package structure tends to make an 
implication that it relies on the outer package, which in this case it 
doesn't. I'd rather see zope.browser take this role. Perhaps the current 
zope.browser package doesn't have the right name?

Regards,

Martijn

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Jim Fulton wrote:
 On Feb 24, 2009, at 9:26 AM, Tres Seaver wrote:
 ...
 As for TestRequest, I could update the setup.py of various packages
 that
 currently depend on zope.publisher just for TestRequest.  I would
 make
 zope.publisher a test-only requirement.
 Frankly, any code using a testing stub which is that heavyweight  
 needs
 to be refactored.


 There's nothing all that heavyweight about TestRequest.

 - - It derives from BrowserRequest, which means carrying along a *lot*
  of extra implementation baggage.  Tests which use this class, rather
  than stubbing out a dummy request which provides only the API  
 required
  by the application-under-test, will tend to grow unexpected /
  undesirable tentacles to the request implementation.

 - - Using TestRequest involves pulling in all of zope.publisher, a  
 *big*
  dependency;  Shane wants to reduce such dependencies.


OK, I don't agree that zope.publisher is a big dependency, especially  
for code that is meant to run in the context of it.  Any view (or  
resource) code, which is the only code who's tests would need  
zope.publisher, will be used in together with zope.publisher in  
practice.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Stephan Richter
On Tuesday 24 February 2009, Jim Fulton wrote:
  - - Using TestRequest involves pulling in all of zope.publisher, a  
  *big*
   dependency;  Shane wants to reduce such dependencies.

 OK, I don't agree that zope.publisher is a big dependency, especially  
 for code that is meant to run in the context of it.  Any view (or  
 resource) code, which is the only code who's tests would need  
 zope.publisher, will be used in together with zope.publisher in  
 practice.

Yep, I agree.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Stephan Richter
On Tuesday 24 February 2009, Martijn Faassen wrote:
  Packages that depend on those classes usually more or less implicitly
  depend on zope.publisher. So the split might be arbitrary for this
  example.

 My understanding is that Shane is working on an alternative publisher,
 zope.pipeline, that doesn't need this other code. Is that correct, Shane?

I see. He only needs the interfaces, so that he can write compatible code. And 
he is doing some rest-like stuff, so he does not need browser. I would only 
factor out the browser code, if it introduces additional dependencies.

In general I am worried that we are creating too many packages. However, here 
is my order of importance:

1. Minimize dependencies.
2. Minimize packages.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Hanno Schlichting
Jim Fulton wrote:
 On Feb 24, 2009, at 11:12 AM, Tres Seaver wrote:
 - - Using TestRequest involves pulling in all of zope.publisher, a  
 *big*
  dependency;  Shane wants to reduce such dependencies.
 
 OK, I don't agree that zope.publisher is a big dependency, especially  
 for code that is meant to run in the context of it.

I think it's a very subjective and relative measure. Some people call 15
packages a very big dependency. Some measure it in terms of actual
features you get and think it's small.

Hanno

P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
dependency graph ;)

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 11:46 AM, Martijn Faassen wrote:

 Jim Fulton wrote:
 On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:

 I've been working on the dependencies to and from zope.publisher.
 Refining the dependencies should make it easier to integrate
 zope.pipeline when it's ready.

 Can you elaborate on this a bit?

 He has, though perhaps not in an obvious place for you:

 http://shane.willowrise.com/archives/repozublisher/

 http://shane.willowrise.com/archives/redesign-of-zopepublisher/

 http://shane.willowrise.com/archives/zopepipeline/

I disagree strongly with many of the assertions made in these  
articles. (I can't judge the pipeline proposal, since it is only  
fleshed out in code.)  While I do think zope.publisher has some  
problems, they aren't the same problems that shane sees.

...

 I'd like to turn this around a little bit.  Only browser-based code
 should depend on zope.publisher.  This seems like a very reasonable
 dependency.  It's like wxwindows UI code depending on wxwindows.
 Maybe the browser code should be factored out of the packages that
 depend on zoep.publisher so that only *that* code has the dependency
 and non-browser code doesn't.

 Shane, how integrated is code that relies on the pieces in
 zope.publisher you identified into their own packages? I have the
 impression it'll be much harder to go that way than factor bits out of
 zope.publisher instead.

I'd like to see see some specific examples.  In general, in Zope 3,  
we've advocated a separation of model and application code from  
presentation code.  Presentation code is going to depend on whatever  
presentation framework it uses.

 Especially as zope.publisher contains stuff that Shane has no use  
 for with zope.pipeline, and we'd still be pulling it in
 if we didn't do the refactoring.

I'm not sure why this matters. BTW, I suspect we're more concerned  
about odd dependencies *of* zope.publisher, like zope.location. It  
might be better to focus on some of those.

I'd also be in favor of separating out less central parts, like  
support for xml-rpc.

 We got two kinds of browser-based code we should distinguish between:

 * ZMI code

There shouldn't be anything in zope.publisher that depends on the ZMI.


 * framework code that supports the browser

 To get rid of ZMI code, a pattern that works fairly well is to  
 refactor
 everything *else* out of the package and leave the ZMI code in its
 original location, with backwards compatibility imports in place.
 zope.app.* packages frequently can get this kind of treatment.

 Other framework code that supports the browser is much like any other
 framework code. Some packages need to be aware of the browser in order
 to perform their role as framework component at all. If those packages
 can rely on *less* code that would be an improvement.

I'm not sure what you're saying.  If an application package has  
presentation code mixed into it and if there is a desire to use that  
application code in a context without presentation, I'd  separate the  
presentation code from the application code.  The presentation code  
would depend on zope.publisher. The application code wouldn't.

 I'm not very much in favor of making these sub-packages of
 zope.publisher though, as to me a sub-package structure tends to  
 make an
 implication that it relies on the outer package, which in this case it
 doesn't. I'd rather see zope.browser take this role. Perhaps the  
 current
 zope.browser package doesn't have the right name?

I don't know what you mean by these above.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
 
 I've been working on the dependencies to and from zope.publisher.
 Refining the dependencies should make it easier to integrate
 zope.pipeline when it's ready.
 
 Can you elaborate on this a bit?

I've been discussing zope.pipeline on my blog.  I am attempting to 
rebuild the publisher to make it easier to understand and customize.  I 
think it's working out pretty well.  zope.pipeline is intended to 
replace most of the implementation code in zope.publisher and 
zope.app.publication.

To accomplish that, it looks like I ought to separate the 
implementations in zope.publisher from the specifications.  Separating 
the zope.publisher.interfaces package would mostly accomplish that.

After thinking this over last night, I realize that the idea to move
BrowserView, BrowserPage, and TestRequest is driven by the desire to 
clarify the dependency graph.  That's more complex than what I'm trying 
to do and I don't think I need to do that for zope.pipeline, so I'm 
going to withdraw from that part of the discussion for now.

 I've noticed that nearly all packages that depend on zope.publisher
 depend only on a few pieces of it:

   - zope.publisher.interfaces

   - zope.publisher.browser.Browser{View|Page}

   - zope.publisher.browser.TestRequest
 
 
 I'd like to turn this around a little bit.  Only browser-based code  
 should depend on zope.publisher.  This seems like a very reasonable  
 dependency.  It's like wxwindows UI code depending on wxwindows.   
 Maybe the browser code should be factored out of the packages that  
 depend on zoep.publisher so that only *that* code has the dependency  
 and non-browser code doesn't.

I think things are already pretty well factored in that sense.  Take 
zope.formlib, for example.  It wouldn't make sense to separate 
zope.formlib into an abstract package and a browser package, because 
zope.formlib only makes sense for browsers.

Shane

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Hey,

On Tue, Feb 24, 2009 at 6:33 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
 In general I am worried that we are creating too many packages. However, here
 is my order of importance:

 1. Minimize dependencies.
 2. Minimize packages.

+1

I think on the longer term better dependencies can allow us to remove
a great number of packages from the Zope Framework, so I'm not too
worried about the minimization of packages right now. To properly
reduce dependencies you need to go about it in an intelligent way
anyway and do some actual analysis of code, so the new packages that
are created tend to make sense.

Fundamental goals should be:

* Make the code more comprehensible

* Make the code more reusable

The dependency refactoring is not only an effort to make the
dependencies between packages a nicer tree (and thus encourage reuse
of more packages and easier understandability), but also results in
trees that have less code altogether. I think the last point is very
important. Less code might not be reflected directly in the amount of
packages, but is a huge win anyway. Less code makes the code that
remains typically far more understandable and because it pulls in less
baggage also more reusable.

Less code should be evaluated for the whole framework, but also for
each node in the dependency tree.

As an example, zope.site is a new package but contains bits of
zope.app.component and zope.app.folder both. Together with the
creation of zope.container and moving stuff from zope.app.component to
zope.security, we can probably eventually get rid of
zope.app.component altogether, along with zope.app.folder and
zope.app.container. That is a net minimization of packages, and what's
more important, also less code to have to understand.

Regards,

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 I disagree strongly with many of the assertions made in these  
 articles. (I can't judge the pipeline proposal, since it is only  
 fleshed out in code.)  While I do think zope.publisher has some  
 problems, they aren't the same problems that shane sees.

What are the problems with zope.publisher as you see it?

Shane

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Hi there,

Hanno Schlichting wrote:
[snip]
 P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
 dependency graph ;)

That's a cool resource! (the general dependencies folder there)

Are you removing indirect dependencies before generating the graphs? I 
think it is valuable to actually consider the graphs *without* such 
removal being done. I think doing so hides the true complexity of the 
dependency situation and can therefore be very misleading. At least I 
recall the true dependency graphs of something like zope.formlib look a 
lot more hairy than this:

http://hannosch.eu/dependencies/zope/zope.formlib.svg

I highly recommend the use graphviz's sccmap to detect clusters of 
strongly connected components. Circular dependencies are one of our true 
problems and this tool can help you identify them.

It would be nice if we could have a dependency checking service that 
could inform us when we're going in the wrong direction; in particular 
when we create strongly connected clusters.

Regards,

Martijn

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Hey,

Shane Hathaway wrote:
[snip]
 After thinking this over last night, I realize that the idea to move
 BrowserView, BrowserPage, and TestRequest is driven by the desire to 
 clarify the dependency graph.  That's more complex than what I'm trying 
 to do and I don't think I need to do that for zope.pipeline, so I'm 
 going to withdraw from that part of the discussion for now.

If you can make progress without doing so now, by all means. I think we 
do need to get back to this though eventually. It'd be bad to pull in 
code that actually doesn't get used when you use zope.pipeline.

Regards,

Martijn

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Hanno Schlichting
Martijn Faassen wrote:
 Hanno Schlichting wrote:
 [snip]
 P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
 dependency graph ;)
 
 That's a cool resource! (the general dependencies folder there)
 
 Are you removing indirect dependencies before generating the graphs?

Yep. Those are the version with transitive dependencies removed. I work
on this mostly from a Plone perspective, where the full versions are
just utterly unreadable.

But for actual code refactoring and dependency reduction on the zope.*
level the full versions are indeed more useful. I added them now.

The full horror of formlib is available as
http://hannosch.eu/dependencies/zope/zope.formlib-full.svg

 I highly recommend the use graphviz's sccmap to detect clusters of 
 strongly connected components. Circular dependencies are one of our true 
 problems and this tool can help you identify them.

I'll check that out, thanks.

Hanno

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
 P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for  
 the
 dependency graph ;)


That's cool, although wildly inaccurate.  One of the things wrong with  
zope.publisher is that it depends on too many other things.  It would  
be useful to try to clean that up.  A while ago, I proposed a stripped  
down zope.publisher (zope.pub or something) that had a lot less in it, 
http://mail.zope.org/pipermail/zope-dev/2008-March/031170.html 
. I never found time to do this though.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Martijn Faassen wrote:
 The main problem I have with the zope publication machinery is that
 after all these years of using it I *still* get lost in it regularly.
 A more regular architecture that can be traced more easily would not
 only allow better understanding on my part, but might also allow us to
 more easily selectively replace or remove bits of it.

+1.  As I recall, we tried to build a regular architecture in 
zope.publisher using the IPublication interface, but the publisher 
machinery is still painfully difficult to understand without extensive 
study.

I think a pipeline design will make the publisher a lot easier for 
everyone to understand because the pipeline design seems to keep 
concerns closer together.  For example, I've made a traversal module 
in zope.pipeline which has nearly all of the traversal logic in one 
place and almost nothing else.  Its code came from at least 4 scattered 
modules.  Now, in theory, when people want to understand traversal, they 
will usually only need to understand one module.

Shane

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 12:44 PM, Shane Hathaway wrote:

 Jim Fulton wrote:
 On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
 I've been working on the dependencies to and from zope.publisher.
 Refining the dependencies should make it easier to integrate
 zope.pipeline when it's ready.
 Can you elaborate on this a bit?

 I've been discussing zope.pipeline on my blog.

I just looked and I don't see many specifics.  I think I have to look  
at the code and I don't have time for that atm.


  I am attempting to rebuild the publisher to make it easier to  
 understand and customize.  I think it's working out pretty well.   
 zope.pipeline is intended to replace most of the implementation code  
 in zope.publisher and zope.app.publication.

If it is mixing those 2, them I'm not too impressed and I think those  
two packages have very different concerns.

In any case, if what you you really want to do is to standardize some  
common APIs that a number of different publishing implementations can  
use, I'm fine with that.  It should be a new package that has just  
those APIs and that zope.publisher could import.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 1:55 PM, Shane Hathaway wrote:

 Martijn Faassen wrote:
 The main problem I have with the zope publication machinery is that
 after all these years of using it I *still* get lost in it regularly.
 A more regular architecture that can be traced more easily would not
 only allow better understanding on my part, but might also allow us  
 to
 more easily selectively replace or remove bits of it.

 +1.  As I recall, we tried to build a regular architecture in  
 zope.publisher using the IPublication interface, but the publisher  
 machinery is still painfully difficult to understand without  
 extensive study.


Maybe, but I find that people confuse the machinery in zope.publisher  
with a bunch of additional and very confusing machinery in various  
zope.app packages.  The publisher itself is pretty simple.  I think  
this is illustrated by paste.txt in the zope.publisher package.  That  
isn't to say there might not be better models.  Hopefully, I'll find  
time to study your pipeline ideas. I wish there was a proposal I could  
read rather than reading code.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 Maybe, but I find that people confuse the machinery in zope.publisher  
 with a bunch of additional and very confusing machinery in various  
 zope.app packages.  The publisher itself is pretty simple.  I think  
 this is illustrated by paste.txt in the zope.publisher package.  That  
 isn't to say there might not be better models.

I see what you're saying and I agree that the zope.publisher package by 
itself is fairly simple.  However, zope.publisher by itself isn't very 
useful (except in tests), yet zope.publisher doesn't provide all the 
kinds of extension facilities that other packages require.  This has led 
to messy code, starting with zope.app.publication.

Furthermore, I'm not sure anyone can foresee all the ways people need to 
extend zope.publisher.  I think we need a more powerful abstraction.

  Hopefully, I'll find  
 time to study your pipeline ideas. I wish there was a proposal I could  
 read rather than reading code.

I am close to being able to formulate a proposal.  The concept is 
simple: move most publisher functionality into WSGI pipeline stages, 
similar to Repoze.  WSGI pipeline stages are very simple and powerful. 
I had to work out a way to build pipelines with replaceable stages, but 
I think I've almost solved that.

Shane

___
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 3:17 PM, Shane Hathaway wrote:

 Martijn Faassen wrote:
 One question: why is this in zope.app? I think there's a consensus  
 we're
 trying to pull as much from zope.app as possible.

 Is this going to provide a ZMI UI at all? If not, I'd suggest  
 putting it
 in zope.*

 I admit I'm being lazy here.  It seems like zope.app is a dumping  
 ground
 for packages with muddy dependencies.  I didn't want to work out the
 dependency list yet. :-)

 I do have some justification though: it depends on IAuthentication,
 which is in zope.app.security.  Still, I suspect IAuthentication needs
 to be moved out of zope.app.security.


I agree that it shouldn't go in zope.app.  I believe I suggested  
putting this in zc.openid, although I'm fine with zope.openid.

Placement is more a function of project or originating organization,  
rather than dependencies.  The top-level package is determined by the  
project/organization.  Normally, there should be only 2 levels of  
packages. (I screwed up with the zc.recipes package, for example.)

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] SVN: Zope/trunk/ Started on a more high-level `what's new` document

2009-02-24 Thread Hanno Schlichting
Stephan Richter wrote:
 On Tuesday 24 February 2009, Hanno Schlichting wrote:
 +This version of Zope2 is compatible with and is based on Zope 3.5.
 
 Zope 3.5 has not been released. ;-) In fact development has just started. 
 What 
 KGS version do you guys use?

This one:

http://download.zope.org/zope3.5/3.5dev/versions.cfg copied locally into
Zope2 SVN trunk on 2009-02-08 the last time.

Plus a couple of manual updates to packages as per:
http://svn.zope.org/Zope/trunk/versions-zope2.cfg?rev=96902view=markup

Zope 2.11 included Zope 3.4, now its time for 3.5 (which we need for
Python 2.5 / 2.6 support anyways).

We are still in early alpha here. By the time we move on to beta, 3.5
will hopefully have stabilized a bit.

Hanno

___
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 I agree that it shouldn't go in zope.app.  I believe I suggested  
 putting this in zc.openid, although I'm fine with zope.openid.

I'll rename it to zc.openid.

Shane

___
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Dan Korostelev
2009/2/24 Jim Fulton j...@zope.com:
 I agree that it shouldn't go in zope.app.  I believe I suggested
 putting this in zc.openid, although I'm fine with zope.openid.

Why zc? I thought it's only for packages coming from the zope
corporation. Or does Shane works for ZC? :)


-- 
WBR, Dan Korostelev
___
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Shane Hathaway
Dan Korostelev wrote:
 2009/2/24 Jim Fulton j...@zope.com:
 I agree that it shouldn't go in zope.app.  I believe I suggested
 putting this in zc.openid, although I'm fine with zope.openid.
 
 Why zc? I thought it's only for packages coming from the zope
 corporation. Or does Shane works for ZC? :)

This is for a ZC contract.

Shane

___
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] SVN: Zope/trunk/ Started on a more high-level `what's new` document

2009-02-24 Thread Stephan Richter
On Tuesday 24 February 2009, Hanno Schlichting wrote:
 We are still in early alpha here. By the time we move on to beta, 3.5
 will hopefully have stabilized a bit.

What is your time frame for Zope 2.12?

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
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] SVN: Zope/trunk/ Started on a more high-level `what's new` document

2009-02-24 Thread Hanno Schlichting
Stephan Richter wrote:
 On Tuesday 24 February 2009, Hanno Schlichting wrote:
 We are still in early alpha here. By the time we move on to beta, 3.5
 will hopefully have stabilized a bit.
 
 What is your time frame for Zope 2.12?

We'll have a first alpha in the next days. Beyond that we aim for a beta
release in maybe two to three months (Jim agreed on stabilizing ZODB 3.9
in about that timeframe).

There's nothing definitive set here and we are open to change. If I
remember correctly you wanted to aim for a shorter release cycle for
Zope 3 again, by aiming for something like six month.

So if we can aim to have final releases of Zope 2.12 and 3.5 during July
this year, that sounds like a realistic timeframe to me. Of course this
is only a suggestion (and depends on volunteer time and power as usual).

Hanno

___
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Dan Korostelev
2009/2/24 Shane Hathaway sh...@hathawaymix.org:
 Dan Korostelev wrote:

 2009/2/24 Jim Fulton j...@zope.com:

 I agree that it shouldn't go in zope.app.  I believe I suggested
 putting this in zc.openid, although I'm fine with zope.openid.

 Why zc? I thought it's only for packages coming from the zope
 corporation. Or does Shane works for ZC? :)

 This is for a ZC contract.

Ah, then zc namespace if fine of course! :)

-- 
WBR, Dan Korostelev
___
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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Martijn Faassen
Hi there,

I hope in fact zope.app.* will soon become a dumping ground for
deprecated packages providing legacy ZMI support. Of course that will
need the consensus that the ZMI *is* legacy software. I think do we
already have a consensus that packages that provide other useful
functionality shouldn't be providing ZMI support within the same
package.

Regards,

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Jim Fulton wrote:
 On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
 P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for  
 the
 dependency graph ;)
 
 
 That's cool, although wildly inaccurate. 

What's wildly inaccurate about it? Missing transitive dependencies or 
something else?

Regards,

Martijn

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Jim Fulton

On Feb 24, 2009, at 5:19 PM, Martijn Faassen wrote:

 Jim Fulton wrote:
 On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
 P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for
 the
 dependency graph ;)


 That's cool, although wildly inaccurate.

 What's wildly inaccurate about it? Missing transitive dependencies or
 something else?


The graph only shows direct dependencies on zope.i18n and  
zope.security, but there are many other direct dependencies.

Jim

--
Jim Fulton
Zope Corporation


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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Martijn Faassen
Hey,

On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote:
[snip]
 The graph only shows direct dependencies on zope.i18n and zope.security, but
 there are many other direct dependencies.

Ah, agreed, yes, I think this is because of the transitive dependency
functionality removal somehow, even though it seems to remove more
than just these. Hanno's now also generating the real graphs, though:

http://hannosch.eu/dependencies/zope/zope.publisher-full.svg

Hanno, would you consider also generating graphs for the grokcore.* packages?

Regards,

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Hanno Schlichting
Martijn Faassen wrote:
 Hanno, would you consider also generating graphs for the grokcore.* packages?

Can you point me to a buildout or virtualenv-friendly way of getting an
environment with those? Than it should be rather trivial to do for me.

Hanno

___
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] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working

2009-02-24 Thread Hanno Schlichting
Tres Seaver wrote:
 Hanno Schlichting wrote:
 Andreas Jung wrote:
 On Mon, Feb 23, 2009 at 17:46, Tres Seaver tsea...@palladion.com wrote:
 Creating an instance from the SVN checkout itself doesn't work for me
 either for the same reason. The created scripts try to use the general
 Python interpreter without the correct sys.path and end up missing out
 all the dependencies.
 
 Right:  if you hack it to use the 'zopepy' script, rather than
 sys.executable, then the instance scripts work.

I looked at this, but guessing or reliably getting to the zopepy script
wasn't possible. So I added an explicit option to the script instead and
documented it. You can now use:

bin/mkzopeinstance --python=bin/zopepy

on the SVN trunk. You can omit this option and it will use
sys.executable as before.

Hanno

___
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] Consensus on the ZMI and zope.app.* namespace. (Was: SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3)

2009-02-24 Thread Dan Korostelev
2009/2/25 Martijn Faassen faas...@startifact.com:

 I hope in fact zope.app.* will soon become a dumping ground for
 deprecated packages providing legacy ZMI support. Of course that will
 need the consensus that the ZMI *is* legacy software. I think do we
 already have a consensus that packages that provide other useful
 functionality shouldn't be providing ZMI support within the same
 package.

Though it's a very big +1 from me that packages providing useful
functionality shouldn't contain ZMI-related stuff within the same
package, and that's our goal, I wouldn't say that ZMI is a legacy
software, as it's very useful out of box and can be easily extended to
make real use of Zope. I'd rather say that ZMI is an example of
extensible application built on top of zope frameworks and it should
be positioned like that.

BTW, I have a thought about an additional refactoring strategy: we
could move ZMI-related packages to separate packages, like zmi.* or
something, leaving imports in zope.app.* and making zope.app.* really
deprecated. That way we can state that ZMI is not the Zope, but
something built on it. And this way gives us more refactoring freedom
:)

Any thoughts?

-- 
WBR, Dan Korostelev
___
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] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working

2009-02-24 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hanno Schlichting wrote:
 Tres Seaver wrote:
 Hanno Schlichting wrote:
 Andreas Jung wrote:
 On Mon, Feb 23, 2009 at 17:46, Tres Seaver tsea...@palladion.com wrote:
 Creating an instance from the SVN checkout itself doesn't work for me
 either for the same reason. The created scripts try to use the general
 Python interpreter without the correct sys.path and end up missing out
 all the dependencies.
 Right:  if you hack it to use the 'zopepy' script, rather than
 sys.executable, then the instance scripts work.
 
 I looked at this, but guessing or reliably getting to the zopepy script
 wasn't possible. So I added an explicit option to the script instead and
 documented it. You can now use:
 
 bin/mkzopeinstance --python=bin/zopepy
 
 on the SVN trunk. You can omit this option and it will use
 sys.executable as before.

Maybe we can detect buildout vs. tarball (e.g., the presence of
'buildout.cfg' vs. 'makefile'?)


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

iD8DBQFJpIFu+gerLs4ltQ4RAl/9AJ0fs1Re3TPN3ywPAfVO0hf18z9XzwCeNz3u
Zupy2J8xlHfR7jsUTHUFe4U=
=0fQW
-END PGP SIGNATURE-

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


Re: [Zope-dev] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working

2009-02-24 Thread Hanno Schlichting
Tres Seaver wrote:
 Hanno Schlichting wrote:
 I looked at this, but guessing or reliably getting to the zopepy script
 wasn't possible. So I added an explicit option to the script instead and
 documented it. You can now use:
 
 bin/mkzopeinstance --python=bin/zopepy
 
 on the SVN trunk. You can omit this option and it will use
 sys.executable as before.
 
 Maybe we can detect buildout vs. tarball (e.g., the presence of
 'buildout.cfg' vs. 'makefile'?)

What you have available inside the mkzopeinstance script is:

sys.executable which is just your regular Python interpreter and then
sys.argv which is ./bin/mkzopeinstance.

As the 'zopepy' script can be called anything, I don't see how you can
be smarter here.

Hanno

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Martijn Faassen wrote:
 Hey,
 
 On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote:
 [snip]
 The graph only shows direct dependencies on zope.i18n and zope.security, but
 there are many other direct dependencies.
 
 Ah, agreed, yes, I think this is because of the transitive dependency
 functionality removal somehow, even though it seems to remove more
 than just these. Hanno's now also generating the real graphs, though:
 
 http://hannosch.eu/dependencies/zope/zope.publisher-full.svg

I see in that graph a number of dependencies that are pulled in just for 
specifications.  For instance, zope.publisher doesn't really need the 
Location class, it only needs ILocation.

Just brainstorming, but I wonder if we shouldn't split at least the 
following packages into specification and implementation packages:

   - zope.location
   - zope.security
   - zope.i18n
   - zope.publisher
   - zope.component

That way various packages could use i18n interfaces without pulling in 
pytz, or could use location interfaces without pulling in zope.proxy, 
and so on.

Brainstorming deeper: we could apply a naming convention where the 
specification package is named with the suffix spec, so zope.location 
would be split into zope.location and zope.locationspec.

Shane

___
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] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working

2009-02-24 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hanno Schlichting wrote:
 Tres Seaver wrote:
 Hanno Schlichting wrote:
 I looked at this, but guessing or reliably getting to the zopepy script
 wasn't possible. So I added an explicit option to the script instead and
 documented it. You can now use:
 bin/mkzopeinstance --python=bin/zopepy
 on the SVN trunk. You can omit this option and it will use
 sys.executable as before.
 Maybe we can detect buildout vs. tarball (e.g., the presence of
 'buildout.cfg' vs. 'makefile'?)
 
 What you have available inside the mkzopeinstance script is:
 
 sys.executable which is just your regular Python interpreter and then
 sys.argv which is ./bin/mkzopeinstance.
 
 As the 'zopepy' script can be called anything, I don't see how you can
 be smarter here.

I'm not worried about generalities:  I think that 'mkzopeinstance'
should work from inside a SVN checkout of the Zope2 trunk, where the
script is going to have a known hame.  Something like this::

- --- src/Zope2/utilities/mkzopeinstance.py (revision 97232)
+++ src/Zope2/utilities/mkzopeinstance.py   (working copy)
@@ -50,6 +50,9 @@
 skelsrc = None
 python = None

+if check_buildout():
+python = os.path.abspath('bin/zopepy')
+
 for opt, arg in opts:
 if opt in (-d, --dir):
 skeltarget = os.path.abspath(os.path.expanduser(arg))
@@ -186,5 +189,14 @@
 fp.close()
 os.chmod(fn, 0644)

+def check_buildout():
+ Are we running from within a buildout which supplies 'zopepy'?
+
+if os.path.exists('buildout.cfg'):
+from ConfigParser import RawConfigParser
+parser = RawConfigParser()
+parser.read('buildout.cfg')
+return 'zopepy' in parser.sections()
+
 if __name__ == __main__:
 main()




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

iD4DBQFJpJgO+gerLs4ltQ4RAqR1AJ9OBXJ7NNDkG5wc0aKAapvDoZbeIQCYsJfH
6jyjW7e7X5XXBE2G6xJX8w==
=ha/A
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Stephan Richter wrote:
 On Tuesday 24 February 2009, Shane Hathaway wrote:
 Brainstorming deeper: we could apply a naming convention where the
 specification package is named with the suffix spec, so zope.location
 would be split into zope.location and zope.locationspec.
 
 what about zope.ilocation?

Maybe.  I'd lean toward zope.locationspec because it would appear 
right after zope.location in a sorted list, making it more apparent that 
they are related.

Shane

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


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Lennart Regebro
On Wed, Feb 25, 2009 at 04:05, Shane Hathaway sh...@hathawaymix.org wrote:
 Stephan Richter wrote:
 On Tuesday 24 February 2009, Shane Hathaway wrote:
 Brainstorming deeper: we could apply a naming convention where the
 specification package is named with the suffix spec, so zope.location
 would be split into zope.location and zope.locationspec.

 what about zope.ilocation?

 Maybe.  I'd lean toward zope.locationspec because it would appear
 right after zope.location in a sorted list, making it more apparent that
 they are related.

zope.location.interfaces?

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Baiju M
On Wed, Feb 25, 2009 at 12:39 PM, Lennart Regebro rege...@gmail.com wrote:
 On Wed, Feb 25, 2009 at 04:05, Shane Hathaway sh...@hathawaymix.org wrote:
 Stephan Richter wrote:
 On Tuesday 24 February 2009, Shane Hathaway wrote:
 Brainstorming deeper: we could apply a naming convention where the
 specification package is named with the suffix spec, so zope.location
 would be split into zope.location and zope.locationspec.

 what about zope.ilocation?

 Maybe.  I'd lean toward zope.locationspec because it would appear
 right after zope.location in a sorted list, making it more apparent that
 they are related.

 zope.location.interfaces?

This will not make any change in dependency graph unless zope.location
become a namespace package.


--
Baiju M
___
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 )