Hi John, [...]
> I'm okay with the attributes being shared between the application and > the framework. Just need to document it really well (in > particular how > to handle clashes/errors) and have some good examples. The example > that you have is a good start but it doesn't deal with the > uncomfortable case of a naming clash and what happens and what the > developers can/should do about it. For example, what happens > if I try to set a Location: header in a redirect response vs. setting it in a "normal", non-redirect response? The proposition I made (and the current implementation) forbids the *addition* of *standard* HTTP headers. They can only be read for incoming requests (server-side) or outcoming responses (client-side). This way no conflict is possible. Also, as one goal of the Restlet API is to provide full coverage for the HTTP 1.1 protocol features (while staying open to other special features of other protocols), we should have provisions for getting/setting all necessary info directly in the object API. For example, the Location header is mapped to the Call.redirectRef property. I've made the Javadocs of Call.getAttributes() even more explicit about this: checked in SVN. Thanks, Jerome
