FYI, The default media type is already defined as "*/*" in spec I
believe. It should stay that way.
On 4/12/11 7:25 AM, Adam Bien wrote:
> JAX-RS CoC should align with JPA, EJB 3.1, CDI "style" first. We need to
> agree on a default MediaType, method, Path etc. I think default values
> are easy to derive if not obvious. This is essential and "critical".
>
> After the definition of the defaults we could think about "pluggable"
> CoC. From my point of view it would be prio 2. Agreed?
>
> On 10.04.2011, at 15:54, Guilherme Silveira wrote:
>
>> Hi Markus,
>>
>> An interface with one method that receives one string and returns
>> another is not a complex one in my point of view. Its only more
>> complex than a interface with no methods.
>> Although 80% is surely great, 100% with 10 extra lines of spec sounds
>> better for me. 3 for the interface less than 7 for explaining how it
>> works.
>>
>> Of course, this is the interface for the case in discussion. It could
>> be improved in several ways.
>>
>> Regards
>>
>>
>>> On 10/04/2011 4:59 PM, "Markus KARG" <markus_at_headcrashing.eu
>>> <mailto:markus_at_headcrashing.eu>> wrote:
>>>
>>> Guilherme,
>>>
>>>
>>> with the target "CoC" im mind, looking at the *average user* of
>>> JAX-RS, I cannot find a better word than "rocket science": If a
>>> *user* would be clever enough to implement such an interface, he
>>> wouldn't have a need for CoC IMHO, since CoC in my experience is most
>>> appreciated not by *lazy* people but more by the "not-so-skilled"
>>> ones (in other words, users like CoC because they don't need to
>>> understand what's going on or what the correct syntax would be like
>>> ["it works somehow magically"], not because they do understand how to
>>> configure but just don't want to type the stuff in). That's why I
>>> think for *those* people (in my experience: the majority of average
>>> users) to get the largest benefit of our CoC efforts, the need for
>>> understanding such a complex interface would be experienced as being
>>> "rocket science" so they wouldn't use it at all. But if people don't
>>> use it largely, there is no justification to provide a standard for
>>> it. So it could be a really useful extension of your framework, but I
>>> just don't see that it is so wide-spread needed that we should define
>>> a standard for it. In my opinion, our CoC target should be to define
>>> that 80% of use cases that people would love to see a simple "best
>>> CoC guess" built into JAX-RS, not to define an API for the other 20%
>>> experts that just are too lazy to type. But that is just *my*
>>> opinion, maybe the other experts think different.
>>>
>>>
>>> Regards
>>>
>>> Markus
>>>
>>> *From:*guilherme.silveira_at_gmail.com
>>> <mailto:guilherme.silveira_at_gmail.com>
>>> [mailto:guilherme.silveira_at_gmail.com
>>> <mailto:guilherme.silveira_at_gmail.com>] *On Behalf Of *Guilherme Silveira
>>> *Sent:* Samstag, 9. April 2011 23:27
>>>
>>>
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>>>
>>> Subject: [jsr339-experts] Re: Annotations CoC [Was: Convention Over
>>> Configuration]
>>>
>>>
>>>
>>> If its out of scope I can understand. But I disagree about its
>>> difficulties, or even rocket sciwnce. Extracting simple interfaces
>>> should be easier to do than agreeing whether a rest consumer should
>>> be bound to its server interface.
>>>
>>>
>>>
>>> Regards
>>> >
>>> > On 09/04/2011 4:34 PM, "Markus KARG" <markus_at_headcrashing.eu
>>> <mailto:markus_at_headcrashing.eu>> wrote:
>>> >
>>> > While obvious...
>>>
>>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com