> Fra: Shawn McKinney [mailto:[email protected]] > Sendt: 23. februar 2016 22:23 > > On Feb 23, 2016, at 12:36 PM, Jan Sindberg <[email protected]> wrote: > > ... > > The clients may implement this if they so choose so what advantage is there > for us to implement?
The more complete solution we offer ... I want performance but also cheap operations costs. Based on that I accept our operations choice of hosting. That hosting comes with limited CPU power and therefore bad performance. We are also an international company, and that introduces network latency and more trouble for performance. Although I speak from our experience, I believe that there are many others which are in a similar situation. With homemade caching also comes the trouble of ensuring synchronized data - in our case the BA opted for a timeout on the cache, otherwise we would have to hack Commander to send events, or hook into ApacheDS. The drawback of this solution is that you cannot shut down a user instantly, which I don't think is in the spirit of best practice security. That depends on the timeout and therefore you would like a short timeout which then begs the question of what was gained in perceived performance? Caching client-side might somehow question the accelerator effort ? In summary: The benefits would be a more "complete" plug'n'play product which guarantees performance in most circumstances and ensures best practice within security. Still configurable policies must exist for when network connection to main DS is lost. - the solution with embedded ApacheDS (thanks, Emmanuel, I forgot we already had that discussion) could act as an emergency brake in case of lost connection to the main DS in the rare situation where you at the same time needs to shut down a user or just modify permissions for some high-profile customer right now - although that has its own twists like running a commander agaings that or opening Apache Studio and editing the raw entries directly (not so nice).
