Hi Angela,
thanks a lot for the good explanation about how you got where SPI is
now. More inline...
Angela Schreiber schrieb:
I'm currently looking at SessionInfo (in the SPI API) and
SessionImpl.logout() (in jcr2spi).
It seems that the Session logout is handled entirely by the transient
layer, and no SPI method is called to forward the information that the
Session isn't used anymore. On the other hand, the SPI implementation
may want to free resources related to the SessionInfo, right?
Am I missing something, or is this an oversight?
you don't miss anything, nor is it an oversight.
it's simply an open issue and there are many opinions, that
don't fit together.
- initially the requirement was, that there is no (and never)
a 'session' hold on the server-side (server in the broader
sense). in this situation, both login and logout
didn't make any sense, since they insinuate, that there might
be some session hold below the SPI boundary.
this was the very initial state, where no 'login' was present.
Understood, and makes sense.
- later on, some people claimed, that the 'SessionInfo' interface
is lost in the SPI and that it should be define, how the
SessionInfo is obtained.
in this situation, we added the 'login' method (which is probably
misnamed given the requirement). the current api reflects
this state.
- after that the login method has been a questioned in the first
jsr283 f2f and later on, since people thought, that 'login'
implies a stateful implementation.
Of course it begs the question where logout is :-)
- and currently there a multiple requests for a 'logout' method,
in order to be able to keep some sort of Session identification
on the 'server'.
so... :)) since marcel and myself were busy with all kind of
issues (mainly due to the id, that isn't an id any more),
we didn't feel like fighting with opposed requirements
and postponed the discussion (and a careful evaluation of all
the pros and contras).
Some thoughts:
1) an SPI implementation of course will need to know on whose behalf
requests are made; so at the very least some kind of user identification
is needed. We currently have that in SessionInfo.
2) In many cases, an SPI implementation will also need to authenticate,
thus it will need credentials. That's also in SessionInfo.
3) In some cases, an SPI implementation will have to keep it's own
sessions open communicating to it's backend (JDBC connections, for
instance). Of course an SPI implementation can control their lifetime
(for instance, implementing a pool), but knowing when a session for a
particular user isn't needed anymore would be very useful in any case.
So based on this I would recommend keeping SessionInfo, potentially
rename "login" to something else ("obtain"?), and add a matching cleanup
method ("close")...
Best regards, Julian
