Hi Guillaume,
it sounds good. Thanks for the update.
Regards
JB
On 02/27/2014 12:54 PM, Guillaume Nodet wrote:
I'm experimenting with the API i proposed earlier, but what I'm playing
with right now is, in addition to a cleaner Action model API, an
abstraction of the console, so that the command model only depends on the
console api.
This way, we should be able to have an action model that works on a
pluggable console implementation.
It should allow using actions or any other model (plain gogo) on top of a
console which can run in osgi, non osgi, gogo or not and jline or not.
I'll keep you posted on my experiments.
Guillaume
2014-02-27 11:26 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
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é <j...@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 <bcanh...@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 <
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/>
--
Jean-Baptiste Onofré
jbono...@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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
