On 04/12/2013 11:59 AM, Chris Withers wrote:
On 14/03/2013 08:01, Marius Gedminas wrote:
What's the official location of RelStorage? I see two source trees:
* http://zope3.pov.lt/trac/browser/relstorage/trunk
* https://github.com/zodb/relstorage
They have the same commits (~1 year
On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
The ZMI is a highly insecure, completely outdated and user-unfriendly
interface.
As I read this, I got an idea for a possible way forward. I haven't
been reading zope-dev much lately, so forgive me if something like this
has been mentioned
On 04/04/2011 10:22 AM, Roger wrote:
Just because you can write login forms with
z3c.form this package has nothing to do with
authentication. That's just a form framework!
Authentication is defently not a part
of our z3c.form framework and should not
become one.
Why do you think
On 03/21/2011 10:59 AM, Chris McDonough wrote:
On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote:
It's easy and clear, but has the drawback of encouraging that
registration is done on import time, while scanning separates the
registration from the definition. I'm not sure how important
On 12/07/2010 12:27 PM, Chris McDonough wrote:
I *think* I'm of the opinion that libraries (or even reusable
applications) probably shouldn't need to use includeOverrides.
+1, I would be very suspicious of any library that uses
includeOverrides. Any use of it ought to be highly visible to
On 07/02/2010 11:49 AM, Tres Seaver wrote:
Jim has asserted (but not really explained) that the C extension closes
some kind of security hole. I don't see any credible attack vector
myself, but then I no longer believe it worthwhile to devote my own
energy to defending against malicious TTW
Christian Theune wrote:
This is a mailinglist and you probably have dumped your address book to
the invitation system. I've seen a couple of those talk to Zope
mailinglists recently. Can you *please* avoid putting mailing list
addresses into those systems?
Better yet, I wonder if there is
Jan Ulrich Hasecke wrote:
On 04.01.10 19:23, Baiju M wrote:
Hi All,
I am proposing to call Zope 3 - the web frame work
as BlueBream. The main use for name is documentation.
Coming from marketing I strongly suggest to think twice or better thrice
before inventing the next new name
Lennart Regebro wrote:
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote:
Because we have a ton of installed base out there
Do we? I think the debate is somewhat confused here, or possibly it's
only me. :)
I agree that the debate is confused. No one intends to
Hanno Schlichting wrote:
It has a dependency on zope.app.publication. Given the central role of
zope.traversing I allowed it and zope.app.publication to stay in the
ZTK, but moved it to the under-review option.
On the zope.traversing trunk, I have removed the zope.app.publication
dependency.
Martin Aspeli wrote:
Gary Poster wrote:
I think I could get fully behind the following proposal that others have
made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Thinking about it a bit, it strikes me that IFoo.adapt(context) may not
be right. This reads
Wolfgang Schnerring wrote:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
Which will raise
File
Godefroid Chapelle wrote:
I tried to follow this discussion closely: however, I cannot say that I
understand if doing multi-adaptation with IFoo(bar, baz, boo) has been
rejected or postponed.
AFAICT, the decision to reject or postpone that has been postponed. :-)
Shane
Martin Aspeli wrote:
Can we all get back to our lives now? :-)
FWIW, I try to participate in discussions like these by reading and
writing only short emails. I find that I don't miss much that way.
Life is more enjoyable without essay-mails.
Shane
Martijn Faassen wrote:
Given some feedback about backwards compatibility, I'm leaning to the
following adjusted scenario:
* allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation.
It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is*
actually symmetric
Lennart Regebro wrote:
On Mon, Nov 30, 2009 at 19:16, Shane Hathaway sh...@hathawaymix.org wrote:
If adding lookup() is a good idea
Possibly, but it sound like you are looking up (a), when in fact you
are adapting it. :) Maye IFoo.adapt(a) ?
+1, IFoo.adapt() is better, along
Gary Poster wrote:
Then to the multiadapter concern I raised, all my real-world examples
of adapters are to adapt one object so it can be used in a certain
way (to integrate with another kind of object). Power adapters, for
instance, adapt a plug (required interface) so it can plugged in to
Martijn Faassen wrote:
But someone needs to think of a feasible upgrade scenario. We could
instrument all calls to IFoo and see whether a default argument is in
use, but what then? I'd be hard to distinguish a default argument from
one we're meant to adapt. I'd also be non-trivial to scan
Hermann Himmelbauer wrote:
That's exactly the problem - it's a read operation and there should not be
any
write operation involved. However, it's hard to find out where the write
operation in my code occurs, I can't find it in the view, maybe there's
something in the authentication code,
Hermann Himmelbauer wrote:
Hi,
I once in the while get the following warning in my Zope 3 log, which I'd
like
to resolve:
2009-10-07T14:35:41 WARNING ZopePublication Competing writes/reads
at
/BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/c/acc/booklist/index.html:
database
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out. ;-)
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way to clearly
distinguish WebDAV requests, then I imagine this
Hi Dan,
I'll provide feedback for a few parts of your proposal.
Dan Korostelev wrote:
xmlprc - move the IXMLRPCView interface and XMLRPCView base class to
zope.publisher as a counterpart to zope.publisher.browser.BrowserView.
Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive
Fabio Tranchitella wrote:
My knowledge of the zope.publisher is too limited to do any change in this
area, but to me it looks like these configurations (both of them) should be
perfomed by zope.app.publisher (removing the dependency zope.container -
zope.publisher), but conditionally
Fabio Tranchitella wrote:
Is there a specific reason for having the version pinning? Automatic testing
of
zope.tales obviously fails using the KGS, because zope.traversing there is
3.7.1.
Is it possible to remove the versions stanza?
Sure. Pinned versions are OK for a maintenance branch,
Marius Gedminas wrote:
On Sun, Aug 02, 2009 at 08:48:24PM +0200, Andreas Jung wrote:
Hi,
the doctests for zope.index 3.5.2 - as used in Zope 2.12 - fail badly:
File
/home/ajung/.buildout/eggs/zope.index-3.5.2-py2.6-linux-x86_64.egg/zope/index/text/tests/../textindex.txt,
line 143, in
Chris McDonough wrote:
On 8/3/09 1:07 PM, Shane Hathaway wrote:
How insane were these tests? Well, the author of the tests noticed that
the C optimization produces different scores than the Python version,
and compensated for that in a way that dramatically reduced readability.
/me hangs
Hanno Schlichting wrote:
I kind of suspect that we are seeing the results of
http://www.python.org/dev/peps/pep-0353 though.
That is very likely. BTW, that PEP links to a handy tool that reveals
most 64 bit portability issues in Python-oriented C code.
From what I understand we need to
Tres Seaver wrote:
Hanno Schlichting wrote:
Log message for revision 101616: Revert r101557 and put back
version pins for zodbcode and zope.app.interface. These are actual
dependencies of zope.app.zcmlfiles, which in turn is a test
dependency of numerous packages we use. Having a consistent
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL
traversal code would move to zope.tales. zope.container would depend
on zope.tales rather than on zope.traversing.
For my own education, I would like to understand why it makes sense for
zope.container to
Jim Fulton wrote:
On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote:
Jim Fulton wrote:
They wouldn't. They don't use the URL traversal code. Non-URL
traversal code would move to zope.tales. zope.container would depend
on zope.tales rather than on zope.traversing.
For my own
Jim Fulton wrote:
Why? traverseName is part of zope.app.publication's implementation.
Now it's oddly split off in a very separate package.
The publisher traversal code is very similar to the code in
zope.traversing, so I thought the best thing to do is put it in the same
package as
Chris Withers wrote:
It's a shame that the 2 or 3 times I've tried to organise purchase of
ZRS for customers, the Zope Corp sales process hasn't succeeded in
delivering anything :-(
(I'm not 100% on the details, but it may just have been that the prices
were extortionate...)
I disagree.
Hanno Schlichting wrote:
Wichert Akkerman wrote:
[lots of great info about RelStorage]
I couldn't have said it better. :-) Thanks guys.
Shane
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what is the right way to deprecate code, then? I'm not
very happy about including zope.deprecation
Martijn Faassen wrote:
I'm not sure about zope.rest; there's already a z3c.rest which likely
does something quite different, and I think a zope.rest package should
actually *talk* about REST. What about zope.httpview instead?
Well, no, I don't think it's generic enough to call that.
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could
consider changing these deprecations to simple imports if this is
possible...
Certainly, but what
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher, zope.app.publication, and
Shane Hathaway wrote:
Martijn Faassen wrote:
So, the only dependency cycles left in zope.app.publisher are these:
zope.app.publisher -- zope.app.publication -- zope.app.http
I fixed those tonight. On the trunk, there are no longer any
dependencies between zope.app.publisher
Martijn Faassen wrote:
Shane Hathaway wrote:
- I used zope.deferred to deprecate things I moved from
zope.app.publication, zope.app.publisher, and zope.app.http. Are there
any objections to using zope.deferred in those packages?
No objection, but what's the reason to use zope.deferred
Shane Hathaway wrote:
Martijn Faassen wrote:
Shane Hathaway wrote:
In all, I changed 6 packages. Should I release them now, or should I
look for other dependencies we might clean up at the same time?
I'm +1 on releasing now. (and thanks for making them feature releases)
Getting
Martijn Faassen wrote:
Shane Hathaway wrote:
- zope.app.publisher: A library of ZCML directives for configuring
views. Also provides generic view classes. A better name for this
package might be zope.basicviews. A lot of packages depend on this.
I'm not sure 'basic' needs
Marius Gedminas wrote:
On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote:
What about simply calling it zope.view? (I don't like the plural in
package names either generally)
FWIW at some point I decided that singular is appropriate when a package
defines a concept, and plural
Chris McDonough wrote:
On 5/22/09 1:11 PM, Martijn Faassen wrote:
After some work we'd gotten it down to this:
http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg
And by now the main cycles left are these:
http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg
So, the
Martijn Faassen wrote:
It might actually be the best to move these ZCML directives *down* into
zope.component. That won't affect the dependencies of zope.component at
all in fact; the [zcml] dependencies of zope.component already need all
the dependencies that zope.app.component's view and
Andreas Jung wrote:
I will cut a beta 2 release by tomorrow.
Objections?
A couple of bugs have been fixed in ZODB, so it might be useful to get
another ZODB release out first.
http://svn.zope.org/ZODB/trunk/src/CHANGES.txt?view=markup
Shane
___
Jürgen Herrmann wrote:
ZConfig.SchemaResourceError: import name does not refer to a package
Package name: 'relstorage'
File name: 'component.xml'
Package path: None
I need to make a new release of RelStorage before this will work.
RelStorage 1.1.3 does not work with ZODB 3.9, but the
zopyxfil...@gmail.com wrote:
On 27.04.2009 22:56 Uhr, Shane Hathaway wrote:
Lennart Regebro wrote:
Or, we could release 2.12 soon, and then start working on 2.13, a
+1. We need an eggified, Buildout-friendly Zope 2 that's fully
compatible with Zope 2.11.
Zope 2.11
Albertas Agejevas wrote:
On Sat, Apr 18, 2009 at 08:32:52AM -0600, Shane Hathaway wrote:
Given that definition, Zope Toolkit will start relatively small, since
much of Zope 3 does not yet qualify. However, as people refine
packages, the packages will be reconsidered for inclusion in the Zope
Shane Hathaway wrote:
1. Candidate must be have Zope 3 experience.
2. Candidate must be experienced with the Zope Toolkit.
Of course I meant...
1. Candidate must have Zope 3 experience.
2. Candidate must have Zope Toolkit experience.
Shane
Lennart Regebro wrote:
On Mon, Apr 20, 2009 at 18:42, Shane Hathaway sh...@hathawaymix.org wrote:
It occurred to me that one simple test of a Zope naming scheme is to
consider what employers will write in job descriptions.
That's a bloody good point.
Thanks. I take it this point reinforces
Lennart Regebro wrote:
On Mon, Apr 20, 2009 at 23:32, Shane Hathaway sh...@hathawaymix.org wrote:
Also, it follows the open source tradition of slightly whimsical names. The
logo could be a train engine driven by a Zope fish. :-)
Done. Does this mailing list accept attachements?
Wowsers
Martijn Faassen wrote:
You're right of course, I apologize for going that way. I have little
excuse for that.
You've taken a lot of heat in this thread. I hope that doesn't bother
you too much, because I think you're an extremely valuable team member.
This kind of discussion is hard, but it
Martijn Faassen wrote:
Stephan Richter wrote:
On Friday 10 April 2009, Jim Fulton wrote:
Unfortunately these are ZC's use cases.
They are not just ZC's use cases.
Keas is relying on that safety heavily too. Anyone who wants to build a
secure
DSL based on Python really wants zope.security.
Martijn Faassen wrote:
If nobody volunteers to do this (feel free to organize more volunteers),
we'll stick with Zope Framework.
Let me know if you're going to do this and when you're done.
FWIW, I think this particular pile of libraries is in fact best
described by the name framework,
Martijn Faassen wrote:
If we don't call Zope Framework 4.0, we'll be fine. We should call its
first release 1.0 and there's no implication of a progression.
+1 on calling it Zope Framework 1.0. We need the people who have been
burned by past Zope releases to take another look, because we
discussion type=bikeshed
Tres Seaver wrote:
WRT the Framework name: framework is a misleading name for the
collection of packages salvaged from the new Coke effort: it is
actually a *bunch* of frameworks, in the classic software engineering
sense, along with some pure libraries.
Zope
Chris McDonough wrote:
FTR, I do often put
constants in an interfaces.py module at module scope (if there are more than
one related, sometimes in a dictionary or within a non-interface class
statement) in order to not feel I need to create some constants.py module.
Maybe we could just agree
Christian Theune wrote:
I remember that at the sprint we used to identify packages which are
always good. E.g. zope.interface is a declared no-brainer to add to
your dependencies. The other two that keep popping up that we *might*
wanna white-list are zope.schema and zope.component.
To
Roger Ineichen wrote:
What do you do if version x.y works with d.e.d but not with
d.e.e (because it's borken) and fixed in d.e.f.
This means you could use d.e.d or d.e.f. but not d.e.e
What's your solution then?
Fix the version to d.e.d or d.e.f or skip fixing versions?
The version
Stephan Richter wrote:
On Tuesday 10 March 2009, Dan Korostelev wrote:
Either you have a dependency and declare it or you don't have a
dependency. Since we don't want to use extras anymore, I think this
calls for another package which depends on zope.password and zope.schema.
I still don't
Jim Fulton wrote:
I'd rather leave zope.publsiher more or less alone, but develop a new
thing that has the basic/core functionality we need and refactor
zope.publisher to use that. I'd also like to use or be compatible with
WebOb on that. I'd prefer to do this at PyCon where I'll have time
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
I'd rather leave zope.publsiher more or less alone, but develop a new
thing that has the basic/core functionality we need and refactor
zope.publisher to use that.
I had the impression Shane was doing that; i.e. building zope.pipeline
Jim Fulton wrote:
- It's not well enough documented. While I think there's merit in doing
some things at the WSGI level, I remain pretty happy with the
publication interface for separatating generic publisher functions from
application policies. I which the use of this API was better
Roger Ineichen wrote:
Shane,
Can you review and merge this changes into your
zope.pipeline branch?
I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and
I need to discuss it in person; hopefully then I can understand his
opposition and the group can decide on the best
Hi all,
I've put up a draft of a zope.pipeline proposal:
http://wiki.zope.org/zope3/ZopePipeline
The proposal is intended to explain my thoughts on the subject more
thoroughly.
Shane
___
Zope-Dev maillist - Zope-Dev@zope.org
Dan Korostelev wrote:
Also, how easy is to integrate existing non-zopeish WSGI middlewares
into the zope.pipeline? Like some resource injectors or XHTML slimmers
and so on. It would be really great to be able to do that with single
ZCML directive.
You can do that with two ZCML directives. I
Roger Ineichen wrote:
Do you know something about the performance of WSGI?
I whould be happy to see some perfomance tests comparing
WSGI with other server concepts.
WSGI is extremely lightweight, so WSGI itself isn't going to affect
performance. The WSGI servers I know about are reasonably
Martin Aspeli wrote:
I'm used to using Paste Deploy ini files to configure a WSGI pipeline.
Is this simply an alternative to that? If so, do we really need our own
alternative, or could we try to use the Paste Deploy stuff directly?
Yes, you can just use Paste Deploy instead of the
Hanno Schlichting wrote:
What's the overhead of a WSGI middleware? Is the overhead cost in the
same order of magnitude as a simple function call with a return value or
is there something inherently more complex going on?
A WSGI middleware app is simply a callable thing that calls the next
Martin Aspeli wrote:
Shane Hathaway wrote:
Martin Aspeli wrote:
clean_transaction -- is this not the same as repoze.tm2?
No. To mimic the current Zope publisher, we need to commit the
transaction shortly after the call application is finished, but then a
lot of things can still happen
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
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
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
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
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? :)
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
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
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!
Thank you :) I thought about
Fred Drake wrote:
On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton j...@zope.com wrote:
BTW, I strongly discourage from imports. (I didn't always have this
opinion, but have seen the error of my ways. Thanks to Fred Drake for
nudging me in this direction.) IMO, this is wildly more important than
Gary Poster wrote:
We use the OpenID 2.0 identifier select URL. This is a special OpenID
url that
basically means: identity using whatever ID you have on that server.
The OpenID response will contain the actual OpenID identifier of the
user at
the end of the request.
So sites that
Reinout van Rees wrote:
So: easiest way is to let some trusted apache plugin handle the hard
part and then laugh all the way to the bank with some 100-line
authentication plugin.
That would usually work, but in this case, customers will be doing their
own installation, so we need to keep
Today I ran into an exception masked by Zope 3. I found the code that
was masking the exception and fixed it locally, but since this small bit
of code has no docs or tests, I can't be sure I won't break stuff if I
check in my change. What do y'all think I should do?
Here is the patch:
Marius Gedminas wrote:
It's my impression that launchpad.net is an OpenID provider only, while
Shane is trying to figure out how to use the OpenID consumer API in
AuthKit.
No. I am going after the more conventional single sign on use case
where many consumers depend on only one centralized
I'm working with a customer on a single sign on (SSO) system for Zope.
We haven't yet chosen which SSO system we want to use. I would like to
hear from anyone who has set up SSO with Zope.
We have some definite requirements:
* We can't accept arbitrary identities like OpenID normally does.
Hanno Schlichting wrote:
Wichert Akkerman wrote:
I'ld rather not see a whole slew of extra packagse appear. I also wonder
how the extra number of packages and increasing size of sys.path
influence performance and restrictions on environments like GAE.
For environments like GAE you don't
Stephan Richter wrote:
It is finally here! Thanks goes to everyone who involved!
January 29, 2009 - The Zope 3 development team announces the Zope 3.4.0
release.
Excellent!
I have to say, though, that the download process is quite confusing.
Let's say I'm a Pythonista who wants to try out
Tres Seaver wrote:
Is there any reason to hide the KeyError behind a 500, rather than
letting it propagate to the application? In this implementation, we
lose the information about the bad 'status' value.
I agree, but I hit a legacy design snag. The handleException() method
still calls
Benji York wrote:
On Sat, Jan 24, 2009 at 9:43 PM, Shane Hathaway sh...@hathawaymix.org wrote:
Log message for revision 94997:
Corporation - Foundation
AFAIK, the IP hasn't been transfered yet. I'm not sure what the
implications of using Foundation are at this point.
Even so, I have
Hanno Schlichting wrote:
I just checked in another little change that allows you to disable the
persistent product registry and have Zope still work. Just specify
enable-product-installation off in your zope.conf before starting Zope
the first time and watch Zope, CMF and Plone run without any
Chris Withers wrote:
I don't think this is such a huge change, it's a change in the style of
what RP does already, not a complete re-implementation...
OTOH, with Python 3 now released, it seems unlikely that we'll see any
new syntax added to Python 2.x. So RP doesn't really need any sort of
Uli Fouquet wrote:
Ok. I'll put something into the zope.app.authentication branches for
review.
Great!
Two remaining questions: I would like to use `os.urandom` instead of
`random.randint` to create the salt, because this is recommended in
cryptographic contexts. There was, however, a
Uli Fouquet wrote:
Do we need a SMD5-manager as well (same as SSHA, only with MD5 instead
of SHA1 as hash algorithm)?
I doubt it.
Any reviews by the more competent gurus in the list are highly
appreciated.
Your implementation and docs look fine to me. The only comment I have
is I wonder
Martijn Faassen wrote:
Shane Hathaway wrote:
We should really be using the SSHA standard (as defined by LDAP) as a
minimum. SSHA was the default in Zope 2, but someone forgot to bring
this code over to Zope 3.
http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev
Uli Fouquet wrote:
Shane Hathaway wrote:
http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=94737view=markup
Is there some recent documentation about SSHA available? The netscape
links seems to be down.
I'm not sure where to find that documentation now (Mozilla
Uli Fouquet wrote:
Is there some recent documentation about SSHA available? The netscape
links seems to be down.
I finally found a good source. Look at the Python code at the bottom of
this page:
http://www.openldap.org/faq/data/cache/347.html
Shane
Uli Fouquet wrote:
while working on a password manager tool (commandline) for Grok I
stumbled over the usage of salts in the password managers of
`zope.app.authentication`.
In short, they seem to generate (and store) a salt number but do not
make any use of it when it comes to creating the
Dan Korostelev wrote:
I just committed a fix for zope.schema's ValidationError that makes
its repr output more sensible. I'd like community to review those
changes and say if they're okay, because changing exception formatting
syntax will affect doctest so they should be adapted to new style.
Tim Cook wrote:
I DID submit a patch suggestion in the Launchpad bug report.
I think you're talking about this:
https://bugs.launchpad.net/zope3/+bug/301226
Sorry, but the patch doesn't make any sense. Your version of
_validate_fields quietly skips validation entirely by default. Why
Chris Withers wrote:
This is all interesting discussion, but I'd *really* like to know why
subclassing an interface when the C-based implentation is in use doesn't
work.
Does *anyone* actually know the answer to this?
(rather than avoiding it by trying to make the problem something else
Martijn Faassen wrote:
Besides an
import checker you'd need a system that would be able to thrawl through
a ZODB and report deprecated classes. The drawback is that it'd need to
thrawl through a ZODB, so that's rather costly.
Thrawl = thrashing crawl? Never heard that word before, but
1 - 100 of 540 matches
Mail list logo
