On Thu, Jul 23, 2009 at 6:30 PM, Graham
Dumpleton<graham.dumple...@gmail.com> wrote:
> On Jul 24, 5:48 am, Leonardo Santagada <santag...@gmail.com> wrote:
>>
>> I never used this plugin in particular, but if I read the documentation
>> corretly it does two thing, serve trac as a wsgi app (which can be done
>> without a plugin) and permits wsgi apps to be served in the same urlspace as
>> trac. Probably its easy to find in the code how it does this, my guess would
>> be that it redirect requests from trac otherwise it wouldn't need to be a
>> trac plugin, but I'm only guessing.
>

But in process. Doesnt need HTTP redirects ;o)

> Not sure the original poster is clear enough about what he wants to
> do.
>

Well if this is about me then I do know what I want, maybe I wasnt
clear enough :-/

> If all he wants to do is mount two distinct WSGI applications, ie.,
> Trac and something else, at different mount points of the same server,
> then he can use mod_wsgi.
>

No .

> If he wants to actually have the Trac application modify the WSGI
> request environment or request content stream on the way in, or have
> the Trac application modify response headers of response content
> stream on the way out, or use a form based authentication mechanism in
> Trac to control access to the inner application, then he would need to
> use a form of object composition.
>

Almost ... but the fact is that TracWsgi allows for this «object
composition» in a very decoupled and easy manner (using trac.ini as
config and PasteDeploy for hooks to load WSGI apps ;o) . That's why I
like the idea :)

JFYI : I have a WSGI app (let's say a Django or TG or *-based app). I
know how to get the corresponding WSGI app. But I dont want the server
to call this app directly (using mod_wsgi or whatever ;o).

I need that Trac (e.g. handling requests under `trac/`) be able to
process a request to let's say
`/trac/my_hosted_app/anything/further?blah=blah` and, instead of
lookup for a Trac component to send the response back to the caller,
delegate such processing to the aforementioned WSGI app (e.g. Django
app, but just an example, not the real situation ;) and make it
believe that the request was addressed to
`/anything/further?blah=blah` (i.e. WSGI env var PATH_INFO ...
AFAICR).

With the added benefit that (possibly) Trac filters and (possibly)
other Trac features may be triggered.

I knew this was possible in theory, but TracWsgi allows to do this in
a (IMHO) very clean way (and I can save my time ;) and also supports
multiple apps at the same time , using simple config options in
`trac.ini` and therefore it seems to be very flexible.


-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to