There's no simple way to get at 'em, I suppose. So, as a user, how do I determine whether my current set of rules implies a finite expiry limit? If it isn't finite, I'll have to set an explicit @expires; if I do that, it could be too short...
Much along the lines I have carped in another thread: a "clever" system is allright, but it must not leave me in the dark about its cleverness.
Getting down to brass tacks: the stable API should provide access to any data
- set by the user or
- determined by the compiler, and both
- for Java types honed in by DRL declares as well as
- for types declared in the DRL.
Given all that, it might still be useful to have a way of turning the inferred expiry time off
without setting an @expires for all types, which can be done with an @expires(1000000000d) or so). Also, see that hint in a recent thread about how easy it is to implement a retraction strategy based on data in the events. One use case I was thinking of was with events (or even plain facts) having a variable duration attribute, to be retracted at timestamp+duration.
Wolfgang