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 17:38:36 GMT
On 6/23/10 13:11, Guillaume Nodet wrote:
> On Wed, Jun 23, 2010 at 18:39, Richard S. Hall<heavy@ungoverned.org>  wrote:
>    
>> 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.
>>      
> I guess we don't understand each other.   You have made no change at
> all to the existing classes in org.osgi.service.command.  The only
> thing you did is add two annotations.  This is easy to keep backward
> compatibility in that case, because there's nothing to do !!!
> Have a look at 957272 and explain to me where the problem is, because
> to me it looks easy and backward compatible.
>    

The issue as I explained already, we have no rights to publish 
"unofficial" OSGi APIs as "official". It was a mistake for us to ever 
use the OSGi namespace in the first place. Clearly, we are operating in 
a gray area that depends on the niceness of the OSGi Alliance to not 
raise a stink. By putting the packages into our namespace, we are free 
to do the prototyping and there is no IP/legal issue at all.

Even if we don't make any changes to the OSGi API at all, it is still 
the case that this is not official API and there is no way for our users 
to know that.

-> richard

>    
>> ->  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