Re: [Repoze-dev] repoze.component and repoze.configuration

2009-07-01 Thread Tim Hoffman
I use zope.component registrations against interfaces a lot.
It's especially useful for things like view registrations if you models have
an
inheritance hierarchy for their interfaces.

For example it means you can register a default view for a base Interface an
as you develop
more specific views you can register a view at them at a particular subclass
of the base interface.

I think you woul lose that capability with just name based registrations.

Just my 2c worth ;-)

T

On Fri, Jun 26, 2009 at 4:16 PM, Chris Withers wrote:

> Fernando Correa Neto wrote:
> > I'd like to say that repoze.component ended up being more than just an
> > entry point for people willing to apply AOP on their apps.
> > One can easily exercise the pattern of registering components and
> > looking them up back by just using simple strings rather than defining
> > interfaces just as markers.
>
> I have to admit, most of the time I just register components against
> classes, rather than interfaces, when using zope.component.
>
> It'd be interesting to play with repoze.components and see how using
> strings instead feels...
>
> Chris
>
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev
>
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] repoze.bfg nginx mod_wsgi

2009-07-01 Thread Fernando Correa Neto
Hi,

While looking for WSGI support in nginx, I think it would be worth to
take a look at phusion passenger [1] as it claims to support
WSGIeven though their main focus is rails related stuff. Well, at
least it seem to be actively developed and not as stale as mod_wsgi
for nginx.
I should try it myself any time soon.

Regards,
Fernando

[1] http://www.modrails.com/

On Wed, Jul 1, 2009 at 1:35 PM, Nathan Van Gheem wrote:
> Hey Stephan,
> Your insight is pretty much everything I got out of researching too--right
> down to the links.  Too bad.  I'm no sys admin and I hate managing more
> servers than needed.
> I'm glad that I know I'm not missing out on anything though.
> Thanks for the info,
> Nathan
>
> 2009/7/1 Stephan Altmueller 
>>
>> Hi Nathan,
>>
>> We use nginx as our main (and only) web front-end, so I had the same
>> question.
>>
>> I have looked into mod_wsgi and found these two blog posts (not directly
>> answering your question though)
>>
>> http://tomster.org/blog/nginx-mod-wsgi-python2.4
>>
>> http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html
>>
>> Especially the last one (by the author of Apache mod_wsgi) makes a
>> good argument why mod_wsgi (at least in it's current incarnation) might
>> not be a good choice.
>>
>> The point is really that nginx uses asynchronous non-blocking IO, while
>> bfg blocks to load the model.
>>
>> I have thought about what it would take to make nginx work with bfg
>> (or similar WSGI frameworks). I think hat you would have to
>> move around the architecture significantly to incorporate non-blocking
>> I/O.
>>
>> It also seems mod_wsgi for nginx is not really maintained.
>>
>> I am still in the development phase, but right now I am planning on
>> proxy'ing from nginx to an application sever.
>> I have seen several comments that point to FastCGI as a good option.
>> You could also use Apache with mod_wsgi as your app server and proxy
>> to it.
>>
>> I have found quite a lot of information (message boards etc.) on how
>> to proxy from nginx to Pylons apps. Almost all of that should also
>> apply to bfg.
>>
>> Hope this helps, would like to hear if you find out anything else.
>>
>>  -- Stephan
>>
>> Nathan Van Gheem wrote:
>> > Anyone ever deploy repoze.bfg on nginx with mod_wsgi?  Right now I'm
>> > just using proxy_pass to the paster serve for repoze.bfg, but it just
>> > seems more natural if this could be done using mod_wsgi.
>> >
>> > Any thoughts?
>> >
>> > Thanks,
>> > Nathan
>> >
>> >
>> > 
>> >
>> > ___
>> > Repoze-dev mailing list
>> > Repoze-dev@lists.repoze.org
>> > http://lists.repoze.org/listinfo/repoze-dev
>>
>> ___
>> Repoze-dev mailing list
>> Repoze-dev@lists.repoze.org
>> http://lists.repoze.org/listinfo/repoze-dev
>
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev
>
>
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] repoze.bfg nginx mod_wsgi

2009-07-01 Thread Nathan Van Gheem
Hey Stephan,
Your insight is pretty much everything I got out of researching too--right
down to the links.  Too bad.  I'm no sys admin and I hate managing more
servers than needed.

I'm glad that I know I'm not missing out on anything though.

Thanks for the info,
Nathan

2009/7/1 Stephan Altmueller 

> Hi Nathan,
>
> We use nginx as our main (and only) web front-end, so I had the same
> question.
>
> I have looked into mod_wsgi and found these two blog posts (not directly
> answering your question though)
>
> http://tomster.org/blog/nginx-mod-wsgi-python2.4
>
> http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html
>
> Especially the last one (by the author of Apache mod_wsgi) makes a
> good argument why mod_wsgi (at least in it's current incarnation) might
> not be a good choice.
>
> The point is really that nginx uses asynchronous non-blocking IO, while
> bfg blocks to load the model.
>
> I have thought about what it would take to make nginx work with bfg
> (or similar WSGI frameworks). I think hat you would have to
> move around the architecture significantly to incorporate non-blocking I/O.
>
> It also seems mod_wsgi for nginx is not really maintained.
>
> I am still in the development phase, but right now I am planning on
> proxy'ing from nginx to an application sever.
> I have seen several comments that point to FastCGI as a good option.
> You could also use Apache with mod_wsgi as your app server and proxy
> to it.
>
> I have found quite a lot of information (message boards etc.) on how
> to proxy from nginx to Pylons apps. Almost all of that should also
> apply to bfg.
>
> Hope this helps, would like to hear if you find out anything else.
>
>  -- Stephan
>
> Nathan Van Gheem wrote:
> > Anyone ever deploy repoze.bfg on nginx with mod_wsgi?  Right now I'm
> > just using proxy_pass to the paster serve for repoze.bfg, but it just
> > seems more natural if this could be done using mod_wsgi.
> >
> > Any thoughts?
> >
> > Thanks,
> > Nathan
> >
> >
> > 
> >
> > ___
> > Repoze-dev mailing list
> > Repoze-dev@lists.repoze.org
> > http://lists.repoze.org/listinfo/repoze-dev
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev
>
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] repoze.bfg nginx mod_wsgi

2009-07-01 Thread Stephan Altmueller
Hi Nathan,

We use nginx as our main (and only) web front-end, so I had the same
question.

I have looked into mod_wsgi and found these two blog posts (not directly
answering your question though)

http://tomster.org/blog/nginx-mod-wsgi-python2.4
http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html

Especially the last one (by the author of Apache mod_wsgi) makes a
good argument why mod_wsgi (at least in it's current incarnation) might
not be a good choice.

The point is really that nginx uses asynchronous non-blocking IO, while
bfg blocks to load the model.

I have thought about what it would take to make nginx work with bfg
(or similar WSGI frameworks). I think hat you would have to
move around the architecture significantly to incorporate non-blocking I/O.

It also seems mod_wsgi for nginx is not really maintained.

I am still in the development phase, but right now I am planning on
proxy'ing from nginx to an application sever.
I have seen several comments that point to FastCGI as a good option.
You could also use Apache with mod_wsgi as your app server and proxy
to it.

I have found quite a lot of information (message boards etc.) on how
to proxy from nginx to Pylons apps. Almost all of that should also
apply to bfg.

Hope this helps, would like to hear if you find out anything else.

  -- Stephan

Nathan Van Gheem wrote:
> Anyone ever deploy repoze.bfg on nginx with mod_wsgi?  Right now I'm
> just using proxy_pass to the paster serve for repoze.bfg, but it just
> seems more natural if this could be done using mod_wsgi.
> 
> Any thoughts?
> 
> Thanks,
> Nathan
> 
> 
> 
> 
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


[Repoze-dev] repoze.bfg 1.0a8 released...

2009-07-01 Thread Chris McDonough
I know.  This is getting tedious for me too.  But another alpha release 
(hopefully the last) is now in the http://dist.repoze.org/bfg/current index .  
I 
broke down and made ZCML directives for all the "authentication policy" and 
"authorization policy" implementations included in BFG; as a result, the 
"authentication_policy" and "authorization_policy" arguments to 
repoze.bfg.router.make_app are deprecated.  A resource bug was also fixed.

1.0a8 (2009-07-01)
==

- Deprecate the ``authentication_policy`` and ``authorization_policy``
   arguments to ``repoze.bfg.router.make_app``.  Instead, developers
   should use the various authentication policy ZCML directives
   (``repozewho1authenticationpolicy``,
   ``remoteuserauthenticationpolicy`` and
   ``authtktauthenticationpolicy``) and the `aclauthorizationpolicy``
   authorization policy directive as described in the changes to the
   "Security" narrative documenation chapter and the wiki tutorials.

- Add three new ZCML directives which configure authentication
   policies:

   - ``repozewho1authenticationpolicy``

   - ``remoteuserauthenticationpolicy``

   - ``authtktauthenticationpolicy``

- Add a new ZCML directive which configures an ACL authorization
   policy named ``aclauthorizationpolicy``.

- Bug fix: when a ``repoze.bfg.resource.PackageOverrides`` class was
   instantiated, and the package it was overriding already had a
   ``__loader__`` attribute, it would fail at startup time, even if the
   ``__loader__`` attribute was another PackageOverrides instance.  We
   now replace any ``__loader__`` that is also a PackageOverrides
   instance.  Symptom: ``ConfigurationExecutionError: : Package 
   already has a __loader__ (probably a module in a zipped egg)``.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev