<div>(copy of intro that I posted on new members section in the forums).</div><div><br></div><div>Hello Folks !</div><div><br></div><div>I'm a 29 yo R&D programmer currently working at @UK plc (<a href="http://www.uk-plc.net">www.uk-plc.net</a>) in the United Kingdom. I am currently working on a Nginx HTTP authentication module for my company; however I have additional interests in Nginx, I will outline these below.</div>
<div><br></div><div>My Research Work</div><div><br></div><div>I have recently finished a industrial M.Phil with the main software deliverable being a distributed HTTP tracking mechanism. The idea is to track users as they use a web-farm, and do this in a way that the tracking information is present before a request is handled. What this means is that the tracking mechanism needs to be closely coupled to the web-server so that the tracking information can be set as a server/CGI variable. The tracking mechanism has to use the HTTP-cookie mechanism to track state.</div>
<div><br></div><div>Problems that require a tracking mechanism have been solved countless times, so why is my project important ? It is important because the tracking mechanism should be as generic as possible, and this is so that the same mechanism can be used for any sub-system that requires tracking information. The most general application being web-server/web-application/web-framework neutral complex event processing.</div>
<div><br></div><div>My web-server alteration were done under IIS 6 using ISAPI filter / extensions and a custom marshalling service for each web-server. The data was fed into SQL server using a trickle-feed delivery mechanism. Should anyone have further interest, I could send them a copy of my Dissertation.</div>
<div><br></div><div>Interest in Nginx</div><div><br></div><div>The solution of my work is tied to IIS and has a single distributed-software architecture (each server has its own marshalling service). My interests are in implementing the system to enable different topologies, and especially for it to be web-server neutral; the easiest way to enable this is to implement it as a sub-system of a reverse proxy -- which Nginx does marvellously. The original topology needs to be re-implemented as well for composite event processing, and building on the Nginx "engine" seems a natural choice.</div>
<div><br></div><div><br></div><div><br></div><div>As I need a deep understanding of the source base, I have been reverse documenting it for myself. I can perhaps make this available to the community once it is polished enough. I require some knowledge on the semantics of the phase handling (i.e., pre/post conditions and functionality of each phase), and I feel the best way to get this knowledge is to ask it on the developer forum. I could perhaps document it on the wiki once I understand it. Therefore access to the developer forum would be appreciated.</div>
<div><br></div><div>Cheers</div><div><br></div><div>Hassan.</div>