Paul,
> I did not say that. I said what i thought would be *easiest* for the
> developer.
I apologize for misinterpreting your words. I knew I was missing your point
:)
> Rather than the developer having to manage logic and state over a
> sequence of method calls invoked by the runtime (like with
> SAX) they are in control and can choose to keep the state and logic
> local (like with StAX).
I see what you mean. My thought was that the implementation should be free
to call the getLastModifiedDate() method and other methods as many times as
useful and in any sequence.
It seems that this brings the question of the Resource life-cycle. Our
experience with the Restlet API led us to make the Resource class stateful.
Stateful in the sense that the instances are not shared between calls (they
may eventually be pooled). This is different from the rest of our upstream
handlers which are generally stateless (all the changing state is local to
the executing thread).
This approach allows the developer to initialize the Resource state directly
in the constructor and to share this state between the method calls, in the
traditional object-oriented way.
Best regards,
Jerome