I believe the original question was “Does Sling support HTTP Session replication”. Not disagreeing with any of the points being made regarding maintaining RESTful nature of Sling applications (+1 on all of them). But, I believe correct answer is that such capability is not even a concern of a framework like Sling. HTTP Session replication is functionality of application servers. So, if Sling is deployed into app server that supports it then technically it should be possible. Although, it is not recommended.
Cheers, Henry On Sep 22, 2014, at 10:21 PM, Ian Boston <[email protected]> wrote: > On 23 September 2014 00:19, Alexander Klimetschek <[email protected]> wrote: >> On 21.09.2014, at 22:50, Bertrand Delacretaz <[email protected]> wrote: >> >>> What we recommend against is HTTP sessions >> >> ...meaning any in-memory data assigned to some "session" that is kept across >> multiple requests (as that's what J2EE HTTP Sessions are). You want every >> request to be self-describing and able to "start from scratch" to make the >> most out of HTTP and be RESTful. > > +1, > Including any tokens that might authorise the request. i.e. Nothing > stored. Zero server (memory and disk) footprint per client. Capacity > correlated to request traffic, not number of clients. > > Best Regards > Ian > >> >> Cheers, >> Alex
