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 -~----------~----~----~----~------~----~------~--~---