I thought about if I really should answer this, but here we go

2014-02-26 13:43 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:

> Hi Achim,
>
> have you ever asked any developer of commands outside karaf what he wants
> or needs?
> You asume yagni but is it perhaps more like iagni ?
>

Actually I don't care about outside Karaf, cause if you want the features
use karaf. If you can't, stop whining and find a way to use Karaf. It's as
simple as that
If that is still not possible, well live with it. Live isn't Pony-Ranch,
usually you don't get what you want and have to live with it, and make the
best of it!


>
> Are you really sure that an external developer could live with the only
> two alternatives you would give them?
> - Loose all extended karaf features
> - Create two sets of commands
>
>

> I also think we should separate two things here. What I spend my time with
> is mainly my concern.
> The other thing is the impact on karaf. I clearly understand that you fear
> a more complicated code in karaf.
> I can assure you that I will do my best to keep the code simple to better
> support gogo commands.
>
>
You are absolutely right, it is not my business to take care what you do
the whole day, you might as well drill yourself a hole in the head, I
actually don't care.

But what I do care is, does it put a bigger value into Karaf, does it move
Karaf forward.
Is it worth all the hassle, that I do care.
And with only looking at Karaf I don't see the value!

If you want to change gogo, go to felix, discuss it there find a way to get
the felix people to like your ideas. If you're done with that, then we
might have a benefit to use a common implementation.
But OOPS, you still have to convince the eclipse people to use it also. Now
that is something I'd call a challenge.


> There is also a need for a new command API in karaf 4 which Guillaume also
> looks into. I see some good reasons why maybe an extended gogo API may be
> the best fit for us.
> Trying to achieve better support for gogo commands would also give us a
> good chance to see how this alternative would work. So it might help us
> decide
> about the future API.
>
>
As much I've seen so far, all of Guillaumes improvements did focus on KISS.
>From yours I can't say that.


> Christian
>
> Am 26.02.2014 09:48, schrieb Achim Nierbeck:
>
>> But again, this is a propblem which doesn't really concern Karaf. If
>> Camel, CXF, ActiveMQ do need other commands, go create those "striped"
>> commands there, use-case solved (Keep It Simple, Stupid - KISS) [1]. So you
>> should rather spent your time productive on reducing the scope of the
>> commands then another POC that's just another YAGNI (You Aren't Gonna Need
>> It) [2]
>>
>> I'm repeating myself, I haven't seen such people yet, still go back to the
>> basics if needed, provide Commands that fit the environment to run in,
>> instead over-complicating the stuff that works for Karaf.
>>
>>
>> regards, Achim
>>
>> [1] - http://en.wikipedia.org/wiki/KISS_principle
>> [2] - http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
>>
>>
>>
>>
>>
>>> Christian
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>>
>>
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>

Reply via email to