Jerome Louvel wrote:
> 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
> :)
>
No problem! Email much be the source of confusion.
>> 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.
>
Were you also proposing the status should be obtained via a method as well?
> It seems that this brings the question of the Resource life-cycle.
Yes.
> 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).
>
IIRC Marc and I referred to that in previous emails as being per-request
life-cycle.
> 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.
>
Right. This is a key decision the EG needs to make as it impacts the
design of other things.
One very useful thing you can do with per-application life-cycle
(singleton or like servlet) is the caching resource instances, and hence
state. This is used to great effect by Hudson [1], a RESTful extensible
continuous integration Web application. We have used Hudson as a real
world use-case.
We designed the API such that you define an object model of
relationships between resources based on the URI hierarchy. It is
possible for the application to choose whether to use per-application or
per-request when moving through the object model as described by the URI
path, which is consumed based on the URI templates. The closest
documentation i have to explain this is what Hudson uses, called stapler
[2].
It creates a very flexible but intuitive way of building an extensible
web application, for example see the section on stapler polymorphism [3].
To get this more clearly across i think a demo would be best.
Paul.
[1]
https://hudson.dev.java.net/
[2]
https://stapler.dev.java.net/what-is.html
[3]
https://stapler.dev.java.net/getting-started.html
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109