[mapserver-dev] Call for comments - RFC 42 HTTP Cookie Forwarding

[Daniel Morissette]

Daniel Morissette wrote:
> 
>> - Putting processing values in a metadata (http_cookie_data) may be 
>> going to far. The other alternative would be to add a mapfile 
>> configuration parameter called HTTPCOOKIE that would be used to store 
>> the cookie data. I would like to hear from others on that specific point?
>>
> 
> I am also worried that the use of the metadata 'http_cookie_data' to 
> store state information is a poor use of metadata. We could possibly 
> move that to an httpcookie member in the mapObj, but I would definitely 
> not expose it to the mapfile. Since that's state information that does 
> not belong in the mapfile... only the CGI and mapscript need access to it.
> 
> Another idea could be to add an applicationStateObj in the mapObj that 
> could be used to store application state information (like those 
> cookies, and also resultCache, labelCache, etc.)... however that is 
> behyond the scope of the current RFC.
> 


Sorry if I'm talking to myself, I have thought about this some more and 
I propose the following scenario to address the concern of misuse of 
metadata (which I am also concerned with) without having to address the 
wider issue of management of application state information in the mapObj 
in this RFC:

Julien could add an "Implementation Issues" section to the RFC that 
would say something along the following lines:

"""
It was pointed out during the RFC review period that passing and storing 
the cookie data using an "http_cookie_data" metadata is a poor use of 
MapServer's metadata mechanism.

Since MapServer currently lacks a mechanism to associate application 
state information to a mapObj, there is currently no better mechanism in 
place to store the cookie data received from the client and pass it to 
the rendering code that calls the remote WMS. Due to lack of a better 
solution, for the time being we will use the "http_cookie_data" metadata 
as proposed in this RFC, with the knowledge that this is a poor use of 
metadata and that we as soon as a better mechanism is in place to store 
and pass application state in a mapObj then this metadata will be 
deprecated and replaced by this new mechanism. Developers of MapScript 
applications setting this "http_cookie_data" metadata should be aware of 
this and be prepared to change their code in future revisions of MapServer.
"""

Without making any formal committment in the RFC, we should also start 
thinking about a proper mechanism to store/manage application state 
information in a mapObj, that would not only include storing this cookie 
data member, but other existing mapObj members such as resultCacheObj 
and labelCacheObj should probably be handled that way as well.

Since this thread is mostly a dialogue between myself and Julien, I 
suggest that you (Julien) update it based on the notes from this thread 
and open it for vote.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/