Oops. Sorry!
That was really obvious.
Henry
On 29 Nov 2007, at 07:14, Jerome Louvel wrote:
Hi Henry,
The technique to get all server request headers also works for the
client response headers, using the same attribute specified here :
Hi Paul,
I assume you're replying to my comment regarding reflection.
1. I don't want a single converter object to convert more than one
thing. Each converter should convert exactly one thing.
2. Your code doesn't take into account the fact that Foo may be
derived from Bar (and therefore
On Nov 29, 2007 10:57 AM, Rob Heittman [EMAIL PROTECTED] wrote:
Hmmm. I feel myself spiraling back to the interfaces vs classes question.
Don't go into the light! :-) Isn't this just more evidence that it's very
hard to specify interfaces in unstable APIs?
But now you've got me thinking.
On Nov 29, 2007, at 6:30 AM, Tim Peierls wrote:
However, I don't have a concrete proposal, and I don't see an easy
way to do this without breaking code for 1.1m1 users.
Personally, I'd prefer to break an API rather than have to live with
a hacked API forever. Since Restlet is currently a
Isn't this just more evidence that it's very hard to specify interfaces in
unstable APIs?
Yep. And yet, why it's tempting to use them in certain ways. In full
disclosure mode, these public API design questions interest me deeply for
reasons of state not strictly related to Restlet, so
Tim,
I like where you're going with this. Having opt-in interface
inheritance rather than opt-out implementation extension seems a lot
more flexible and a lot lighter weight. Framework helpers, such as
content negotiation, could be injected as (mockable--hah! back to
testing)
Kevin Conaway kevin.conaway at gmail.com writes:
Would it be possible add a new class called URI to facilitate building URIs to
use in client calls? It can be cumbersome to either build the uri as a string
by hand or use the heavy Reference class.I suggest adding a lightweight class
called URI
Hi Mike,
The problem with java.net.URI is that you must specify the URI parts at
construction time. There are no setters and no way to nicely build a URI
piecemeal. That leads to string concatenation and other ugliness
Kevin
On Nov 29, 2007 2:43 PM, Mike Brzozowski [EMAIL PROTECTED] wrote:
To me, the Reference class actually seems quite lightweight and efficient for
the amount of usefulness and flexibility it provides to consumers and mutators
of the Reference. I understand the idea of having nice syntax for building up
a Reference. What if there was something independent,
Hi Jean-Yves,
We have started building support for WADL in Restlet SVN trunk (1.1
snapshot). You should have a look at the org.restlet.ext.wadl extension
Javadocs to see how we have this support for now.
For more details about the current and planned support, have a look at:
Hi all,
This sounds like a very useful idea. What about adding a new
org.restlet.util.ReferenceBuilder class?
It could have methods starting with append like the StringBuilder class,
and follow the Reference naming convention. For example it could have:
- appendScheme(String scheme)
-
It could have methods starting with append like the StringBuilder
class,
and follow the Reference naming convention. For example it could have:
- appendScheme(String scheme)
- appendSchemeSpecificPart(String ssp)
- appendFragment(String fragment)
- appendHierarchicalPart(String ssp)
Hi,
I've got a Restlet 1.0.6-based application and I'd like to implement
authentication for a subset of functionality. There's a nice example of how to
use HTTP Basic authentication, but I noticed there's also a
ChallengeScheme.HTTP_NTLM constant defined. It seems to be relatively
undocumented;
On Nov 29, 2007, at 3:18 PM, Jerome Louvel wrote:
It could have methods starting with append like the StringBuilder
class,
and follow the Reference naming convention. For example it could have:
- appendScheme(String scheme)
- appendSchemeSpecificPart(String ssp)
- appendFragment(String
Oh, no, I'm about to agree unconditionally with Paul. :-)
Why should it enforce the order? The burden should be on the
implementor, not the user. Don't use a StringBuilder: use simple
fields:
class URI {
private String scheme;
private String host;
// ...
}
Yeah, that. The
I have to ask - why not just WebDAV here? Subversion supports it already,
AFAIK.
I tend to agree, but pragmatically it's not that easy. WebDAV isn't quite a
done deal in Restlet yet, though it's possible with some extra flexing, as some
recent threads here rehearse.
And the versioning
On Nov 29, 2007 7:58 PM, Paul J. Lucas [EMAIL PROTECTED] wrote:
On Nov 29, 2007, at 4:52 PM, Tim Peierls wrote:
Abstractly, though, would you rather see ReferenceBuilderException
checked or unchecked in the following:
try {
Reference ref = ReferenceBuilder.appendBar
Order dependence is fine if the fluent interface verbs imply ordering
(appendXXX) rather than not (setXXX). But some of the parts of a URI are
order-independent (e.g., scheme), even if others are not (e.g., path
component). I see no reason to impose an order on the order-independent
parts.
On Nov 29, 2007, at 4:32 PM, Rob Heittman wrote:
The warnings to the user (cough Checked Exceptions /cough) should
come in when you try to confess the builder into a URI, Reference,
or String and it doesn't contain enough pieces and parts to have
meaning.
If, as the implementor, you want
On Nov 29, 2007 4:17 PM, Ben [EMAIL PROTECTED] wrote:
Hello!
In short, I'd like to allow HTTP-based read/write access to a
versioned hierarchical file system. I have a Java client application
that needs to retrieve, modify, create and delete files on a server.
HTTP / REST seems like a good
On Nov 29, 2007, at 4:52 PM, Tim Peierls wrote:
Abstractly, though, would you rather see ReferenceBuilderException
checked or unchecked in the following:
try {
Reference ref =
ReferenceBuilder.appendBar(myBar).appendFoo(myFoo);
// do something with ref
} catch
Since URISyntaxException is checked, I see no reason why the
ReferenceBuilder shouldn't throw a checked exception as well.
I propose the following:
ReferenceBuilder(Protocol, host, port, authority)
// Convenience constructors
ReferenceBuilder appendPath(String unencodedPath);
ReferenceBuilder
22 matches
Mail list logo
