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 old).
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 a
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 a
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 impo
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 TT
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
Lennart Regebro wrote:
> On Tue, Dec 29, 2009 at 22:54, Martijn Faassen 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 declare that
zope.a
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:
> 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
___
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
__
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
> "/h
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.
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 t
Lennart Regebro wrote:
> On Mon, Nov 30, 2009 at 19:16, Shane Hathaway 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 with IFoo
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 symmetr
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 sca
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 co
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:
> databas
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 th
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 (zcml
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
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 dramaticall
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",
>> l
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 ch
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 cons
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
>&
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 de
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 zope.tr
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 disa
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
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
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. z
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 ei
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
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.
>
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 t
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, b
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
&g
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
zope
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.
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
___
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 a
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 th
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 full
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. Development after that should be smoother,
since then we'll all be working with eggs.
Shane
___
Lennart Regebro wrote:
> On Mon, Apr 20, 2009 at 23:32, Shane Hathaway 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?
Lennart Regebro wrote:
> On Mon, Apr 20, 2009 at 18:42, Shane Hathaway 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 poin
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. "Candidat
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 reconsid
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
Chris McDonough wrote:
> On 4/9/09 4:25 PM, 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.
>
> All done except for the renaming of the steering
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"
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 Toolkit, perhaps?
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
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
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 w
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
Martijn Faassen wrote:
>Since ``setuptools`` is a dependency of our packages anyway, we
>can instead do the following::
>
>__import__('pkg_resources').declare_namespace(__name__)
>
>Feel free to use that and also feel free to simplify existing
>``__init__.py`` modules. Jus
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 s
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.pip
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 t
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 d
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 fi
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
a
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 ZCML-ba
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 reasona
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.
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
http://mail.zope.org/m
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 zop
Martijn Faassen wrote:
> Hey,
>
> On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton 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
>
Dan Korostelev wrote:
> 2009/2/24 Jim Fulton :
>> 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
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/
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
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
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 al
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 probl
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
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
Dan Korostelev wrote:
> 2009/2/24 Shane Hathaway :
>> 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 de
Fred Drake wrote:
> On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton 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
>> any o
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
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:
Index
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
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 site
Gary Poster wrote:
> Launchpad uses OpenID. We don't have that slated for abstraction and
> open-sourcing immediately. However, most of the Launchpad code
> (including this bit) is to be open-sourced by this summer, abstracted or
> not. Therefore, we should at least be able to give you some id
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. We
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 d
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
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 s
Benji York wrote:
> On Sat, Jan 24, 2009 at 9:43 PM, Shane Hathaway 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" ar
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 withou
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:
> 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 wonde
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 p
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
___
1 - 100 of 663 matches
Mail list logo