Marc,
> > Yes sure, that's what we will do. But what I actually wanted to say
> > is that
> > in this point, JAX-RS's extensibility is not open enough, since
> > WebDAV is a
> > pretty simple extension to HTTP but already this simple thing is
> > impossible
> > to fit into the framework.
>
> I thought we agreed that it was possible, maybe just not as pretty as
> we'd like ?
Well, if you mean "write your own stuff and use my class inside yours", then
EVERYTHING is "possible". But this is not what "extensible" really means to
the average user of a framework, don't you agree? I mean, writing my own
stuff is not extending, it is bypassing.
> Seems like the Status enum is the main issue. Writing Response and
> ResponseBuilder subclasses should be straightforward.
Sure. One can always write his own classes. But I do not share the opinion
that this can be called "straightforward". "straightforward" in my
understanding of framework design is to provide extension points like
factories or abstract builder methods etc. -- like it was done for Providers
for example, which is a pretty good example for "straightforward
extensibility" in my understanding of the word.
The decision to define Status as an enum made the extension programmer's
life just harder than it would be if it would be an extendable class.
Anyways, you understood the point and it is too late to change anyways.
Don't let's argue. I'll go back to my WebDAV work. :-)
Regards
Markus
>
> Marc.
>
>
> >
> >> -----Original Message-----
> >> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> >> Sent: Freitag, 9. Januar 2009 21:52
> >> To: dev_at_jersey.dev.java.net
> >> Subject: Re: [Jersey][WebDAV]
> >>
> >> All I can suggest is that you write a WebDAVResponse and associated
> >> builder and internally defer to the existing Response and
> >> ResponseBuilder classes whenever possible.
> >>
> >> Marc.
> >>
> >> On Jan 9, 2009, at 2:41 PM, Markus KARG wrote:
> >>
> >>>> Internally ResponseBuilder only uses the int value, see the
> >>>> implementation of ResponseBuilder.status(Status). There are
> methods
> >>>> to
> >>>> set the status code using int and Response.getStatus returns an
> >>>> int.
> >>>> Response.Status is only provided as a convenience and shouldn't
> >>>> prevent use of other status codes.
> >>>
> >>> Yes, certainly one can do that. But see how ugly it is:
> >>>
> >>> ResponseBuilder.status(Response.Status.OK)
> >>>
> >>> compared to
> >>>
> >>> ResponseBuilder.status(WebDavResponse.Status.getInt())
> >>>
> >>> and especielly
> >>>
> >>> ResponseBuilder.ok()
> >>>
> >>> The first one feels intuitive, the second one feels like C++. :-(
> >>>
> >>> Isn't convenience the top idea of the builder API? So if we remove
> >>> convenience, then what is left over that is any better than
> directly
> >>> writing
> >>> "return new Response(200, "OK");" ?
> >>>
> >>> Regards
> >>> Markus
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >>>
> >>
> >> ---
> >> Marc Hadley <marc.hadley at sun.com>
> >> CTO Office, Sun Microsystems.
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net