jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: Nuclear Fission, Splitting the core: The SPI Effect [was: Improving the accessibility of the Jackrabbit core]
Date Thu, 07 Sep 2006 09:38:41 GMT
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

Mime
View raw message