On 6/23/10 11:22, Guillaume Nodet wrote:
On Wed, Jun 23, 2010 at 16:38, Peter Kriens<[email protected]>
wrote:
As the author of the RFC 147 and original author of the gogo code I
concur with Richard and the work we did is very much aligned with the next
version of the RFC which will be discussed in Ottawa. The original RFC has
very strong focus on allowing existing objects (instances!) to very cheaply
provide commands to a shell so the command providers have local context and
the methods provide the type information. I always felt personally that a
class per command was unnecessary complicated, wasteful, and often requiring
statics to find contexts.
That said, I do understand that if someones current command model is very
much based on a command per class than providing a compatibility bundle
sounds like a good idea, it should not be that hard to build this on top of
Gogo, I specifically made sure that the Equinox model could quite easily be
supported without too much overhead. In the vein of OSGi, the best solution
seems to be that it is just done in another bundle, as OSGi was intended to
be. Keeping the core as simple as possible is always nice in the long run
...
Obviously Gogo is independent of the upcoming RFC/spec but as the author
I've no intentions to go beyond the basic model described in the current
RFC.
That's not evident, given Richard said at least twice that those were
to be added to the RFC on this list.
If I should understand by this sentence that you don't intend to
provide a standard way to create commands in the RFC, which i'm all
for leaving opened too.
I don't think that was his suggestion, but I'll let Peter clarify that.
In that case, I'd really suggest the following steps:
* move the annotations into a gogo specific api
See above.
* revert back to the org.osgi.service.command package for the other
existing things
Since we'll be prototyping, we can't wait for RFC releases to do work, so I
don't think moving back makes sense.
* put back the commands module and find a way to rename things to
make it more obvious what is what
We can certainly put it back, but I can just imagine the discussions now:
* "Why won't my commands work in Karaf?"
* "Why doesn't help work for my commands in the framework distribution?"
* "Which approach should I use to create gogo commands?" "This one."
"No, that one."
That's really what should have been done from the beginning and what I
proposed several times on the mailing list.
From that point, having both in gogo would make thing easier to work
together on finding a nice and common approach that would solve all
the requirements. Maybe my point has not been clear, but I don't have
any problem in trying to solve problems with the existing solution and
finding a way to make things better. However, my problem is that
Karaf is already in production, and we should find a smooth way to do
things, keeping the important features such as completion, enhanced
colorized output, etc...
If Karaf depends on prototype API, then that's a risk; however, we can't
lock the API, even better argument for keeping it close to Karaf until a
standard does emerge.
-> richard
Kind regards,
Peter Kriens
On 23 jun 2010, at 15:37, Richard S. Hall wrote:
On 6/23/10 9:14, Guillaume Nodet wrote:
On Wed, Jun 23, 2010 at 14:31, Richard S. Hall<[email protected]>
wrote:
On 6/23/10 5:45, Guillaume Sauthier wrote:
Hi guys
Maybe I react after the battle but, I was quite happy with the
commands
module in gogo :)
I thought it was really some kind of extension to the gogo framework,
not
so closely related to karaf.
We're using it in a chameleon subproject [1] to provide
commands/actions
as iPOJO components.
And we're definitely not depending on karaf, but on gogo.
Is it possible to move back that module into gogo or at least discuss
the
issue ?
Even if it is in Karaf, there is nothing that prevents you from using
it
from there. I'm sure it will continue to be released as a separate
module,
so it doesn't really matter if the groupId is org.apache.felix or
org.apache.karaf.
Ultimately, the commands module was ported from previous
Karaf/ServiceMix
Kernel work and didn't completely fit the Gogo model, which isn't
about
registering Function services as commands, but rather ordinary Java
objects.
So, it doesn't seem fitting for Gogo to promote an approach that isn't
the
intended approach.
That's your view of gogo and please bear in mind your view is not
always
everyone's view nor the only possible view. The
org.osgi.service.command package
defines 4 interfaces, one of them being Function. I can't possibly
imagine how
you can assert that this interface has been designed not to be used.
If you don't want to use it, that's fine. I don't see why this has
to
be *the* way ...
And please, don't say people are free to do it another way, because
that's what
you're trying to rule out by pushing this one into the api and pushing
out the gogo
the previous commands module.
The reality is this:
1. When I started to use Gogo, I tried to use the commands module
first. I found it very cumbersome and unintuitive.
2. I talked with some people about using Gogo and none of them were
using the commands module and specifically Peter Kriens told me
that the Function interface was really only intended for closures
and whatnot and that I should just be using objects with methods.
3. Following Peter's advice, I tried to create commands the way he
suggested, which led to other shortcomings which were corrected by
the addition of some annotations, which were created in concert
with Peter. After that, things went swimmingly.
4. Given that the commands module didn't fit this view and no one was
using it besides Karaf, it seemed to make sense to move it out of
the Gogo subproject.
You may feel that this is forcing out the commands module, but that
certainly wasn't the case given that's where I started. I am not sure why
you feel having a separate module is such a bad thing, since that's the
whole point of OSGi.
And, for the record, I do think it makes more sense for Gogo itself to
promote a single way of creating commands, unless the alternative approaches
are completely compatible with each other and in this case they aren't
really compatible with each other.
-> richard
The RFC behind Gogo is still changing too, so the impl will change to
reflect it. There is some effort to provide similar capabilities in
the core
RFC as to what the commands module provided, e.g., annotations for
describing commands. Hopefully, as it progresses it will subsume the
capabilities of the commands module, but if not, nothing prevents you
from
continuing to use the old version of the commands module (unless there
is
some backwards incompatible change).
-> richard
