felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: Gogo commands module (Was: Re: svn commit: r952918 - in /felix/trunk: gogo/commands/ gogo/commands/src/main/java/org/apache/felix/gogo/commands/ gogo/commands/src/main/java/org/apache/felix/gogo/commands/basic/ gogo/commands/src/main/java/org/apa
Date Wed, 23 Jun 2010 16:52:42 GMT
I might be misunderstood here, I do intend to introduce the annotations in the RFC for discussion
in Ottawa, they do seem to have a lot of value. If they do not provide certain features that
you want to provide then please provide feedback. However, I've to take a deeper look at all
the details and update the RFC. As long as this RFC is not spec, things will be in flux.

I hope to propose a new draft in the next two weeks.

Kind regards,

	Peter Kriens







On 23 jun 2010, at 17:22, Guillaume Nodet wrote:

> On Wed, Jun 23, 2010 at 16:38, Peter Kriens <peter.kriens@aqute.biz> 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.
> In that case, I'd really suggest the following steps:
>   * move the annotations into a gogo specific api
>   * revert back to the org.osgi.service.command package for the other
> existing things
>   * put back the commands module and find a way to rename things to
> make it more obvious what is what
> 
> 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...
> 
>> 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<heavy@ungoverned.org>
 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
>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com


Mime
View raw message