Now that beta 15 is out, let me explain the answers I gave to the
thoughts/questions I raised in this thread:
> 01) an IDENTIFIER references one and only one RESOURCE
Was already supported
> 02) a RESOURCE can be identified by one or more identifiers
Was already supported.
> 03) a REPRESENTATION can also be considered as a RESOURCE in itself
Supported in beta 15, the Representation interface now extends Resource.
> 04) a REPRESENTATION can therefore have IDENTIFIERs (used in HTTP)
Now supported becasue Representation extends Resource, see below.
> 05) the state of a RESOURCE contains a set of IDENTIFIERs and
> REPRESENTATIONs
Supported in beta 15: added getIdentifier(), setIdentifier() and
getIdentifiers() methods to Resource interface. Also added getVariants()
method returning a modifiable list of variants.
> 06) i'm not sure if WORKERs should directly implement the
> RESOURCE interface or only provide a way to
> identify/instantiate RESOURCES
The concept of WORKER was generalized into the one of HANDLER, which is also
a super interface of ROUTER, FILTER and SCORER. It does contain a
findNext(Call) method returning the next Restlet. So, a Resource can be
returned because in beta 15, the Resource interface extends Restlet.
> 07) a REST call invokes a standardized METHOD on an
> identified RESOURCE
Yes, and this contract is now fully supported by the Resource interface
which extends Restlet. Therefore any method can be handled by a Resource.
The AbstractResource class automatically implemented the GET method based on
the exposed variant representations (getVariants()), doing some content
negotiation.
> 08) the identification task is currently handled by a tree of
> MAPLETs (or ROUTERs)
True, the renaming of MAPLET to ROUTER was done in beta 15.
> 09) a RESOURCE is stateful (owned by one thread)
False, it is up to the developer to decide on this. It is totally possible
to have stateless Resources, similar to EJB Session beans, for example for
POST processing purpose.
> 10) a CHAINLET (or FILTER) is stateless (shared by multiple threads)
True, this is now enforced by the Restlet API as class attachment was
removed in beta 15.
> 11) a MAPLET (or ROUTER) is stateless (shared by multiple threads)
True, this is now enforced by the Restlet API as class attachment was
removed in beta 15.
> 12) a WORKER would also be stateless (shared by multiple threads)
HANDLERs introduced in beta 15 are intended to be stateless.
> 13) can't we merge WORKER with ROUTERs so that we could
> directly attach RESOURCEs (class) to them?
No because, there is often the need to provide some custom logic to
(re-)instantiate the target Resource, especially if it is statefull. Like if
a database request is required. So, frequently there will be a
ResourceHandler between the Router and the target Resource, responsible for
this lookup/instantiation.
> 14) should we rename REPRESENTATION into CONTENT or ENTITY
> and add a new REPRESENTATION interface that would extend both
> CONTENT and RESOURCE (to support the idea that a
> REPRESENTATION is a RESOURCE while keeping a clean/simple
> interface to deal with content).
Instead of separation, the Representation was merged with
RepresentationMetadata, but there is a more precise contract (new methods)
to deal with the actual content of the representation which can be served
fresh multiple times (when technically possible). See "transient"
properties/methods added in beta 15 on Representation.
> 15) in order to support the "vary" header for content
> negotiation, we need to add a way to know/tell the variant
> dimensions (language, encoding, media type, client address,
> user agent, custom, etc.)
Added an issue to bugs database.
> 16) support the "Content-location" header by identifying
> output REPRESENTATIONS
The "outputRef" property ends up in this "content-location" header for HTTP
server connectors.
> 17) support the HTTP status 300 (multiple choices) when the
> content negotiation is not applied (or can't be applied)
Added an issue to bugs database.
> 18) if we refactor REPRESENTATION as proposed above, we could
> add a property for the parent/represented RESOURCE
Was already present in beta 14!
> 19) should we rename REFERENCE into IDENTIFIER to be more
> consistent with the REST terminology or keep the current term
> which is used by the URI standard?
No we'll keep the current approach, a REFERENCE is different as it may
contain extra information, like a fragment part. However, the related
methods on Resource interface are named using the "identifier" root.
> 20) should we rename "redirectionRef" into "contentRef" or
> better "outputRef" to support specifying the IDENTIFIER of
> all REPRESENTATIONs, and not just for redirections? No need
> for that if we allow the setting of a REFERENCE or IDENTIFIER
> for each REPRESENTATION
"redirectionRef" was renamed to "outputRef" in beta 15. We also have to
ability to set identifiers for Representations in beta
