Hi Galder, regarding the "Client Identification" paragraph I was thinking of the connection there might be with authenticated session ids I describe in the security document [1] in order to reduce the potential proliferation of identifiers.
In the "security case" it is the server who is generating a unique session identifier at the end of a successful auth handshake. Such an identifier is then sent back from the client for all subsequent requests to avoid re-authentication. My plan was to tie this session id merely to the user's principal but this would not allow recognizing a dropped/restarted client. My proposal is therefore that the HotRod protocol should add just one element which can serve both purposes. Tristan [1] https://github.com/infinispan/infinispan/wiki/Security On 12/05/2013 05:16 PM, Galder Zamarreño wrote: > Hi all, > > Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events > > Thanks a lot for the feedback provided in last thread. It was very > constructive feedback :) > > I've just finished updating the design document with the feedback provided in > the previous email thread. Can you please have another read and let the list > know what you think of it? > > Side note: The scope has got bigger (with the addition of > filters/converters), so we might need to consider whether we want all > features in next version, or whether some parts could be branched out to next > iterations. > > Cheers, > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev