Hi Thomas, Thanks for your thoughtful comment.
I don't understand why it needs to be stateless (about my understanding of stateless, see http://en.wikipedia.org/wiki/Stateless_server). As far as I see stateless means it's slower, and I really don't like slow ;-) Even HTTP is becoming more and more stateful to improve performance I guess. Maybe Roy could give his view about stateless versus stateful. I know there are some other advantages / disadvantages.
Hmm... I am not sure if I would agree with the "generally slower" statement, but I completely agree that this touchy topic. I remember a somewhat lengthy verbal discussion revolving around that a similar topic. Some of the legacy repositories that may want to implement the SPI are stateful, which makes it less intuitive for them to implement a completely stateless SPI. I still have not found a completely satisfying solution for that, but somehow it would be great if a well-behaved client could issue something like login() and possibly logout() to indicate to the server that some heavy-weight resources can be disposed. I think I understand that something like that could possibly break the stateless contract, but it could solve a very practical need. I could envison something along the lines of passing something like a "token" (or a "cookie" to borrow an HTTP analogy) on the login() call which would be passed back to the "server" on subsequent calls to help identify the "server"-session. Of course the "server" should also be able to work without this "token" but from a performance perspective would be capable of optimizing the use of some of its resources. What do you think? regards, david
