Steve, Any sample code? Specifically, what algorithm do you use to generate a unique session ID? If it's not too much extra work, I might favor the non-cookie approach. I'm somewhat of a purist, and I like the idea of writing a service that could work over other protocols or with generic clients, even if in practice we only use the HTTP/.NET combo.
Andrew > > Stan, > > > > Thanks! I was talking about application scope because it looked like > > that's what would be necessary to track multiple sessions on the server >via > > "pure" SOAP (passing the session ID in the SOAP headers and not relying on > > HTTP headers). But if cookies are a standard feature of .NET web service > > clients, great! I haven't done much with .NET yet. > > > > Andrew > >I dont like cookies as a way of modelling session state; they are too much >classic web browser and should not be transferred into the new API world, >especially when some implementations (can you say >java.net.HttpUrlConnection) make a dogs breakfast of handling >1 cookie). > >I am putting session into the API itself, which makes it explicit to >everyone, and then doing my own mapping from a session ID to stateful >objects. This also makes testing easy, you dont need SOAP or HttpRequest >mock objects to call into your stateful stuff at test time
