On Mar 10, 2008, at 3:10 PM, Bill Burke wrote:
>>
> I want the Representation thing *and* the ability to use an
> OutputStream.
So many demands ;-).
> Let me summarize:
>
> * MessageBodyReader/Writer is nice because it allows the spec and
> vendor implementations to prepackage handling of certain Java and
> mime types.
>
And applications to add support for arbitrary types... You seem to
think that its a huge burden to implement MessageBodyWriter in an
application but I don't understand why ? You have to implement three
methods (two of which are trivial) and add an annotation, why is that
so hard ?
> * OutputSTream is nice because its a model programmers are used to
> and provides a very simple way of streaming dynamic data.
Agreed, noting the downside of tying up a service thread.
> It also helps in tangent use cases like the transactional BLOB one
> I gave before.
>
I thought the returning an InputStream solution I gave was neater for
an SQL blob which already exposes its data in that way.
> * Representation is nice because it gives the application developer
> the ability to define entity processing dynamically on its own.
>
I could see adding something along the lines of what you and Stephan
suggested, e.g.:
public interface StreamedOutput {
void write(OutputStream o);
}
Which can be returned when you want to do streaming - the spec would
require implementations to support this type. I'm not a huge fan of
anonymous inner classes, but they can be useful. Given the above I
don't see why you'd also need another way of getting an output stream...
Beyond that though I think that Response and ResponseBuilder already
support the metadata side of Restlet's Representation class and I
don't see the need to add more of it. A Restlet-based implementation
could support the Restlet Representation class directly if desired.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.