<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/06/16 16:31, Bill Burke wrote:<br>
</div>
<blockquote
cite="mid:1abe4774-e203-5296-4702-af5eab085bdf@redhat.com"
type="cite">First on pagination. I was thinking about this a
bit. Do we really think that admins are going to paginate through
1000s of users? Or will it be more like a couple of hundred at
most? Right now I've implemented something that is pretty
inefficient to keep it backward compatible right now. Basically I
iterate all providers from the beginning until the page desired is
identified and filled up. Minimally it is a stop gap until I get
everything working.
<br>
<br>
The API will need to change if we want pagination to work
efficiently. Invokers on the API will need to keep an index as we
need to know the last provider queried and what was the index for
the last entry read. As a result, the REST API would have to
change too.
<br>
<br>
On 6/23/16 8:53 AM, Stian Thorgersen wrote:
<br>
<blockquote type="cite">Some comments on
<br>
<a class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI">https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI</a>:
<br>
<br>
* Different cache policies per provider may be difficult.
Wouldn't that
<br>
require having a Infinispan cache per provider? That wouldn't be
very
<br>
manageable.
<br>
</blockquote>
<br>
I think there is some flexibility here in the Infinispan API. I
know the old api at least allowed you to define zones in the
cache.
<br>
</blockquote>
The Infinispan has method like "put(<span style="color:#20999d;">K </span>key,
<span style="color:#20999d;">V </span>value, <span
style="color:#000080;font-weight:bold;">long </span>lifespan,
TimeUnit unit)" . So if the only difference is expiration time for
different users, then it might be sufficient?<br>
<br>
Marek
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<br>
<blockquote
cite="mid:1abe4774-e203-5296-4702-af5eab085bdf@redhat.com"
type="cite">
<br>
<blockquote type="cite">* My vote goes to remove
UserFederationProvider unless it has no impact
<br>
on design of the new providers. We shouldn't sacrifice the
<br>
usability/design of the new SPI for the sake of this.
<br>
</blockquote>
<br>
With what I got so far, I've written it to be completely backward
compatible and allow them to co-exist.
<br>
<br>
<blockquote type="cite">* We should be careful about changing
behavior of LDAP provider as it's
<br>
supported in product
<br>
</blockquote>
<br>
Honestly, we made a very bad decision to not refactor the
federation SPI and to force users to import. It is going to be a
really big headache to migrate existing LDAP users to the new LDAP
provider. IMO, it is ultra important to stop importing
everything.
<br>
<br>
<blockquote type="cite">* JTA - should we support proper JTA
transactions for consistency?
<br>
<br>
</blockquote>
<br>
Yes, but not all federation providers will be able to take
advantage of it, i.e. LDAP.
<br>
<br>
Bill
<br>
</blockquote>
<br>
</body>
</html>