<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 9/20/16 2:30 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A1C6DF@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<pre wrap="">I think there's a separate problem, due to artifact usage (I'll admit that it's an edge case, but just go with it). If the algorithm is to walk the tree to index what's in the directory, then you can do an in-memory index and dual-index by hash and entityID.</pre>
</blockquote>
<br>
Fwiw: That is exactly the reason why I concluded that, for the
persistent backup cache case, at init-time you have to iterate the
cache and process all the entries, in at least some minimal fashion,
in order to produce those indexes. And then I realized: that's the
expensive part; once you've done that, you may as well just keep in
memory as the live data.<br>
<br>
Since that's way up in the abstract base class, that also affords
the possibility to index on arbitrarily anything (similar to the
secondary indexes in the batch resolvers) and not make assumptions
specific to what capabilities or limitations (identifiers) are
inherent to the concrete resolution strategy.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A1C6DF@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap=""> But if the idea is to ignore what's actually there and just compute requests on-demand, </pre>
</blockquote>
<br>
That was my plan for the "local dynamic" one. To not iterate and
index. It's more like the MDQ server case, where any specific
capabilities around supported identifiers are inherent to a
particular deployment.<br>
<br>
An MDQ server isn't going to support arbitrary identifiers, only
specific ones, based on software and configuration. A local dynamic
one would have the same characteristic, I think. So that's why you
don't need to iterate and index. The thing populating the directory
"indexes" them (by filename) according to whatever capabilities the
resolver is going to support.<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A1C6DF@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">you can't do that on the IdP's end by entityID since you might only have the source ID of an artifact. Using the hash as the name gets you both at once.</pre>
</blockquote>
<br>
Yes. If we go with a single transform function, that is the
argument for SHA-1 hash. However, as I (mildly) objected at the
time, artifact source ID isn't strictly defined as the SHA-1 hash of
the entityID, that's merely the common and suggested convention
(albeit the vast majority one). This is admittedly an even more
edgy case than what you brought up.<br>
<br>
And so it occurs to me that having multiple strategies applied in
order might be one way to solve this "multiple identifier" problem.<br>
<br>
(And of course on Unix/Linux something like symlinks could be used
to support aliases so that a given entity has multiple ways it can
be resolved. Theoretically.)<br>
<br>
Another way is to build intelligence into the concrete resolver,
such that it produces a different candidate identifier depending on
the criteria that was supplied.<br>
<br>
I'm still working on and thinking about this part. Will probably
get to later this week after I finish the filesystem plugin stuff.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A1C6DF@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
The MDA isn't trying to solve that problem, isn't it the thing *producing* the files in the directory?
</pre>
</blockquote>
<br>
I don't know if your question was directed to me or Tom, but I
haven't really thought much about how MDA fits into this. Although
I guess it's kind of obvious that *something* has to produce the
folder o'metadata, and MDA seems like the obvious choice....<br>
</body>
</html>