karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Ideas about karaf and gogo commands
Date Thu, 27 Feb 2014 10:26:15 GMT
If my proposals sounded like THE solution I must apologize. It was not my
intention. Somehow my style of writing things often seem to be perceived in
this way. I am aware of this and am trying to improve my style. If you hit
such a mail by me I will be happy about some personal feedback.

About the proposals. They are indeed rather far from being even a coherent
solution. I am still experimenting and am not even sure about the best way
for a command api from my point of view. My intent was just to summarize
the current situation and give some inspiration on directions for
improvement. I also wanted to inform you what I intend to look into. One
thing we could already work on is to find the goals of the karaf community
regarding the command api. I listed the goals I have but I would like to
hear what goals others have for a future API and solution. I think in
design there is no absolute good and bad. You can only judge a design based
on the goals you have. So I think the most important thing we can do right
now is to define the goals as a community.

Christian



2014-02-27 9:56 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> Hi,
>
> gentlemen, calm down and try to focus on the ways to improve Karaf.
>
> Christian presented a proposal for discussion, Achim replies with
> pros/cons: it's the Apache way and that's why it has to be discussed.
> We just have to say in a polite and constructive discussion.
>
> When we propose a new feature/change, we have to be ready to accept
> critics (and don't think we have THE solution, maybe we don't see the
> complete picture), and on the other hand, when describing pros/cons on a
> proposal, it should be done in a gentle, polite, and constructive way.
>
> I think that Christian proposal has very interesting values, especially
> about a commands API. The details should be polished (for instance, I'm not
> yet sure that gogo shell is good basement), but we can move on and look
> forward on some detailed discussion.
>
> Achim also expressed a good point: keep it simple, not reinvent the wheel.
> I take it more like a general reminder for all of us: we did a great work
> in Karaf in term of end-user convenience, flexible features, etc. Some part
> are very "Karaf centric", and it makes sense to provide something more
> generic and flexible if you want to increase the popularity of Karaf. On
> the other hand, those changes must not break the existing and implemented
> as an atomic plant ;)
>
> So, let express constructive critics (a critic can be negative or
> positive) and move forward all together to build a better Karaf.
>
> As reminder: personal promotion, selfish, pedantic, etc don't take place
> in Apache projects (and OpenSource projects in general). We are dedicated
> to the users and the community, always listen our team mates, committed on
> the project. The project doesn't belong to anyone, it belongs to everybody,
> including the users.
>
> Thanks guys
> Regards
> JB
>
>
> On 02/27/2014 09:21 AM, Christian Schneider wrote:
>
>> Hi Achim,
>>
>> I accept you opinion yet with some disappointment about your ignorance of
>> the outside world.
>> I hope this does not refelect the whole karaf community.
>>
>> JB and Guillaume seem to be fine with improving the gogo support.
>>
>> As for the KISS principle. I think the gogo command style follows this
>> principle better then the karaf Action style. You can simply export a gogo
>> command class as a service. So you are really just exposed to the API. For
>> DS this also means
>> that there is no need for any extender. Can it be more simple like that?
>>
>> In our Action case there always has to be a Command adapter that needs to
>> be pulled up and exported as a command. Guillaume did some great work to
>> make the usage of Action in karaf as easy as possible and it helps us a
>> lot.
>> Still the gogo model is just simpler in its core. So I think we should at
>> least consider it too. Especially when we think about a new API for karaf
>> 4.
>>
>> What I miss from all your mails is some real technical arguments. Your
>> arguments are just I don't need it and I don't care about the outside
>> world. This style of discussion reminds me more of politics than apache.
>> As
>> said above I accept this as your opinion. So I am fine if you do not want
>> to go into more details.
>>
>> Christian
>>
>>
>> 2014-02-27 6:58 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com>:
>>
>>  I thought about if I really should answer this, but here we go
>>>
>>>
>>> 2014-02-26 13:43 GMT+01:00 Christian Schneider <chris@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/>
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message