To implement trust policy, we need a way for applications and libraries to control the context of when they accept content -- to apply their own policy about what content is "good" for a given use. However, we need those constraints to potentially be effected down at the lowest levels of the stack, so for example, retrieval code can go back for a "better" object after rejecting a bogon, without having to redo parts of the content search. Our current approach to that is allowing low-level code to call up to higher-level code for input on content acceptability at the point of retrieval. However, not all the plumbing is there to make this generally useful and used; that plumbing is necessary to allow people to experiment effectively with trust models.

Both for filter registration, and for specialized applications using CPU-poor devices (e.g. sensor networks) there may be situations where symmetric MACs are more appropriate than public key signatures. To allow experimentation with such mechanisms, we need to make sure the plumbing for the signing/verification code can handle a wider notion of signing key and signature.

I handed this off to Michael yesterday for review and merge, branch f-100154-encr-cache-flag.
Michael, if you've merged it, pass it on to Jim.

set to false by default.

Long since merged.

I think given the way pipelining works it doesn't necessarily make sense to change the way we do this, at least at this point. (I'd have picked "rejected" but that wasn't an option I could pick.)

And it should ideally be possible to set them as a group -- e.g. a SystemTimeouts object, where we have different subclasses of SystemTimeouts pre-tuned for particular situations or platforms, and can eventually make SystemTimeouts return dynamic values in response to adaptation.

We need to be able to manipulate timeouts for some kinds of situations which may require longer than usual timeouts.

This can cause the test to fail in some environments

need to make sure nothing depends on this behavior before fixing it. Used in the SecureKeyCache constructor that loads from a KM.

Yup, that's what Rebecca said, too. I've got this fixed on a branch.

Yeah... JUnit used to have a TestSuite notion that allowed you to order tests, but it got removed for reasons I've never entirely understood.

Usually what we do if there are tests with strong order dependencies is to collapse them into a single actual @Test that simply runs the components in the right order. Not as many cool green JUnit checkmarks, but a lot less time wasted being mystified by tests that don't behave.