Re: HTTP Headers

2007-04-13 Thread Dig

Jerome Louvel contact at noelios.com writes:

 Hi Dig,
 
 Complete caching support is not available in the API yet. It is planned for
 a future release, see: http://restlet.tigris.org/issues/show_bug.cgi?id=25
 
 You are touching a sensitive point. I have relaxed the usage of the standard
 HTTP headers that are not yet supported in the API. You will still get a
 message in the logs (INFO level instead of WARNING), but it will work.
 Checked in SVN.
 
 Also, I have entered a new issue to keep track of all unsupported standard
 HTTP headers:
 http://restlet.tigris.org/issues/show_bug.cgi?id=282
 
 Best regards,
 Jerome  


Hi Jerome,

Thanks for the response - very helpful. I'll implement these 
headers once I upgrade.

Best regards,

Dig.



Re: Request for change to Representation

2007-04-13 Thread Thierry Boileau

Hello Justin,

we are pleased to receive such a gentle post, thanks a lot. We 
understand your point of view, which is mainly based on an early 
validation at instantiation time (fail fast).
Instances would be absolute, or relative and resolvable. They would be 
safe from the beginning and therefore could be used more safely. 
Each time the developper is willing to update parts of the Reference 
which can break the safeness, he would take some precautions and make 
some precondition tests (like invoking isRelative() method).


However, the way the Reference class has been designed is quite 
different and is mainly based on a late validation. It allows 
flexibility for the developper, because the reference can evolve 
according to his wishes, a Reference can be used to store data (relative 
or absolute), to be shared as a base between several references, etc. 
For example, it can be useful to manipulate a relative reference with 
any base reference specified, as long as you don't need to resolve it of 
course. The drawback is that the resolution of the Reference may fail 
because of the absence of some of the prerequisites. Developpers may 
have to take some precautions and do some precondition tests before 
attempting to resolve their references (like invoking isRelative() method).


We don't say one of the approach is better than the other, it's mostly a 
matter of preference and design choice. Our priority is to ensure that 
the behaviour of Reference is clearly understandable. Also, we are ready 
to consider additional methods (maybe a validate method) that would 
help developpers be confident of the completeness and resolvability of a 
reference.


Best regards,
Thierry Boileau


Gentlemen,

Currently, a Reference instance may be in any state from empty, to invalid, to
relative, to absolute.  In any of those states it may or may not have a baseRef.
 No exceptions appear until certain getter methods are called.

I agree that we should be able to modify the parts of a Reference, but I will
argue the flexibility of having a Reference which cannot be resolved to an
absolute reference (e.g., relative internalRef with null baseRef) introduces
problems which are difficult to validate after the fact.

I humbly request that the Reference class attempts to be fully-resolvable. 
This would require at least the following changes:


- remove default constructor
- validate that uriReference is absolute in constructor Reference(String
uriReference)
- validate that uriReference is relative in all Reference(Reference baseRef,
...) constructors
- isRelative() based on presence of baseRef
- set* methods on relative Reference throw IllegalArgumentException if
applicable (callers can use isRelative() to check beforehand)

These changes would allow some measure of consistency, keep the flexibility of
modifiable references, and simplify working with deep Reference chains.  I
imagine it would also simplify some of the code.

Your thoughts?  And, yes, since I'm making the proposal, I would be willing to
do the work.

  


Re: Question to all about visual webapps and Restlet

2007-04-13 Thread Vincent
Hi Matthieu,


 Basically I've a rich client application (Flex) accessing 

Ah, but it's quite a different story, as the final (visual) representation is
assembled on the client, not on the server.

  I considered each resource as
 being kind of a virtual web page, with one URI and  one (or several if
 required) layouts (representations). The application accesses the  required
 resources, and assembles them for display. 

So if one page displays A and B, and another page displays A, B, and C,
 A knows it has two layouts (a/B and A/B/C). If you later add D to the page,
you'll add a third layout for A. Is that correct?


 
 An important point is that each resource includes links to all other
 resources it is logically linked to: the client has absolutly NO 
 knowledge of the links between resources, it virtually navigates between
them as needed. If A is linked  to A and B, when the client accesses A it
  receives its representation, including a link to B and a link to C;

Let say these resources are independent one of another (For instance if 
A is a weather report, B a news feed, and C your profile). Who is responsible 
for linking them together? Does A know it's linked to B and C, or are these
associations established at a higher level?

A's representation contains a link to B and C, which means the client has 
to GET  and C, and pass their representation to the template in order to
generate the page. So, do B and C's representations contain links to A?

-vincent.