Directly parse Request, send Response from/to Mongrel2 protocol

[Sergey Shepelev]

Hello.

If someone heard of any work on using Webob with Mongrel2 protocol without WSGI? Of course it is impossible as is, but surely Request could get another constructor and similar work with Response.

What is Mongrel2: http://mongrel2.org/

[Sergey Schetinin]

Most of webob request properties operate on the wrapped wsgi environ,
so I don't think it's possible to cut wsgi out of equation even less
so, given that the request object is mutable.

> --
> You received this message because you are subscribed to the Google Groups
> "Paste Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/paste-users/-/qGQDNw7i2jAJ.
> To post to this group, send email to paste...@googlegroups.com.
> To unsubscribe from this group, send email to
> paste-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/paste-users?hl=en.

[Jim Fulton]

Why don't you want to use WSGI?

There are several bridges between mongrel2 and WSGI.

I tried one a few months ago when I was playing with mongrel2.
It worked. :) I don't remember which one it was.

Jim

[brad clements]

I have looked at http://wsgid.com/ and it seems ok.

My concern with this style is that I want to move authentication up 
into mongrel2, rather than forcing all of my backend workers to 
understand web authentication (also having to connect to an ldap server 
or similar)


For example my paste apps have authentication nearly at the root of their pipeline, lower level app components do not worry about authentication.

When using mongrel2, if each worker is like a 'lower level app', then all those workers now need to handle authentication.

[Sergey Shepelev]

Surely i will resort to WSGI in the middle now that Sergey says it's
hard to overcome it.

Primary reason to avoid it: cut what is not used. Trying to keep
things straight and simple. Pays off with speed, memory and ease of
debugging.

Brad: unfortunately, i had opposite experience with wsgid. Don't like
to be forced to organize my application with directory structure of
author's taste, forces outdated pyzmq==2.1.10, exits with code 1 and
no messages for some combination of command line flags - no way to
know my mistake.

[Jim Fulton]

The mongrel worker could be the "server" for whatever WSGI stack you want.

Jim

[Ian Bicking]

On Tue, Mar 27, 2012 at 2:08 PM, brad clements <bkcle...@gmail.com> wrote:

I have looked at http://wsgid.com/ and it seems ok.

My concern with this style is that I want to move authentication up 
into mongrel2, rather than forcing all of my backend workers to 
understand web authentication (also having to connect to an ldap server 
or similar)

Then I assume Mongrel2 is sending authentication information in its messages, and you should be sure that information ends up in the environment somewhere.  It probably does, it looks like one way or another everything in the message is translated into something in the environ (https://github.com/daltonmatos/wsgid/blob/develop/wsgid/core/wsgid.py#L168) – having a canonical translation from Mongrel2 to WSGI would be nice though, instead of just relying on the conventions wsgid has implemented.  But that's just a matter of agreeing on names.

Sergey: I don't see any substantial per-request overhead in wsgid.  If wsgid's loader is annoying... then you should submit a patch ;)  But the basic approach – normalizing from Mongrel2's message format to WSGI – is reasonable and as efficient as can be expected.  For WebOb to be agnostic would introduce just as much overhead for everyone as what wsgid is doing.  Basically wsgid just has to translate Mongrel2 dicts to WSGI dicts.

  Ian