I think so. I was really looking for what the interface was going to
look like - some set of canned mechanisms that we provide that work
within the various source environments or merely a Java API that the
users are responsible for implementing and using for each source. It
sounds like it might be the latter.
Randall Hauch wrote:
The thought was that the cache would operate in a manner similar to
DNS: each source is able to define the cache requirements/parameters
for each piece of data it returns. Each source would also have a
default policy (requirements/parameters) that would be used if none is
provided by the source, and the federation engine could have its own
default policy. Thus, the federation cache would hold onto each node
until: 1) it expires or 2) until it receives a notification from the
source that it has changed or has been removed.
Does that answer your question?
Regards,
Randall
On May 14, 2008, at 4:13 PM, John P. A. Verhaeg wrote:
> The getting started documentation discuss providing support for
> sources to push change notifications to the DNA server to, for
> instance, trigger when a source's cache should be expired in a
> federated repository. What is the current thinking for how or what
> will be provided to facilitate this?
> _______________________________________________
> dna-dev mailing list
> dna-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/dna-dev