felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
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:39:50 GMT
On 6/23/10 12:08, Guillaume Nodet wrote:
> Letting a project evolve and breaking the compatibility for the sake
> of it is a different problem.   In that case, your modifications could
> have been done without infringing the IP and keeping backward
> compatibility.
> Given how easy is it, i'm going to do that in trunk.    I'd rather
> have those as a separate module, but I agree it's slightly more
> difficult to do.
>    

Given our changes already impact the defined behavior as well as the 
signatures of the API, I don't agree that it is that easy and certainly 
won't stay that easy in the future.

-> richard

> On Wed, Jun 23, 2010 at 17:36, Richard S. Hall<heavy@ungoverned.org>  wrote:
>    
>> On 6/23/10 11: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.
>>>
>>>        
>> 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<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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>
>>>>>>              
>>>>
>>>>          
>>>
>>>
>>>        
>>      
>
>
>    

Mime
View raw message