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 <[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.
> 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<[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
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
