> A new developer,
> just coming to maintain a particular project, would have to 1st look at the
> configuration file to see how it behaved, then the documentation of the CoC
> plugin.
Yep, in 20% of the cases where he needed to configure something, he
would need to look at one interface with a single line of code
implementation.
If he had no CoC configuration, the config would be spread all over
his project in annotations in multiple classes.
Its a trade-off. Configuration spread all over your project x one
place. It has its + and -.
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Mon, Apr 11, 2011 at 7:33 AM, Bill Burke <bburke_at_redhat.com> wrote:
> My biggest problem with pluggable Coc is that the same exact piece of code
> could behave differently depending on how you deploy it. A new developer,
> just coming to maintain a particular project, would have to 1st look at the
> configuration file to see how it behaved, then the documentation of the CoC
> plugin.
>
> Personally, I've always hated implicit "magical" behavior when having to
> debug or refactor somebody elses code.
>
> On 4/10/11 3:58 AM, Markus KARG 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] *On Behalf Of *Guilherme Silveira
>> *Sent:* Samstag, 9. April 2011 23:27
>> *To:* 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 obviously CoC is something that is really beneficial to the
>> user's productivity, I do not think we could find a real
>> justification for adding another complex API for a pluggable rule
>> set (it would be counter-productive since it is another thing to
>> learn and support). There are other items besides CoC of much higher
>> and global interest in our stack, so we should keep things simple in
>> this area and just think over a few places where CoC makes really
>> sense instead of doing rocket science.
>>
>>
>> > -----Original Message-----
>> > From: Marek Potociar [mailto:marek.potociar_at_oracle.com
>> <mailto:marek.potociar_at_oracle.com>]
>> > Sent: Frei...
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>