[SCR] Dropping the proprietary extensions for the R7 implementation

[Carsten Ziegeler <cz...@apache.org>]

I would like to simplify the upcoming R7 implementation of Declarative
Services and drop the support for the proprietary extensions.

Currently the implementation supports two additional namespaces for the
component XML. The oldest one allows to define an updated method before
it became part of the R4.2 release. So this has only been used
temporarily until that release became official.

Similar, there is a special namespace for the R4.3 release which can be
used to indicate that the components might return additional service
properties from the activate method. This feature has been discussed at
that time in the OSGi expert group and was not rejected. While there
might be some people using this, this is tied to the 4.3 specification.
So as soon as you want to use R5 or R6 features or in the future R7
features, this proprietary extension is not available to your component.

My suggestion is we drop these things for the R7 version and simplify
the implementation in some areas. If users want to use those features
the R6 implementation is still there to be used and we can maintain it.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [SCR] Dropping the proprietary extensions for the R7 implementation

[Carsten Ziegeler <cz...@apache.org>]

Actually I was wrong with the below statement. There are the Felix
proprietary namespaces in addition with extensions you can use as
attributes in the component XML. So these extensions work with any
namespace. That somehow voids my argumentation. :(

So let's keep the stuff in

Carsten


Carsten Ziegeler wrote
> My point is, if you use the extension you can't use a R5,R6 or R7
> feature with that component.
> 
> Then we have things like FELIX-5775 where the code involved got so
> complicated because of the proprietary support that I could find no way
> to make this work when the extensions are used.
> 
> Regards
> 
> Carsten
> 
> 
> David Jencks wrote
>> As I recall, the behavior of all the extensions are available in the R6 version through the use of the ds ext annotations which get compiled into Felix namespace xml attributes by bnd. What exactly are you proposing removing?
>>
>> I don’t think the top level xml namespaces offer much value but I’m not sure the code supporting them is complex enough to worry about. For the most part I think the behaviors of the extensions are fairly useful so I’d be reluctant to remove them. Making an osgi server that uses them not able to upgrade to r7 is a pretty big restriction.
>>
>> David Jencks 
>>
>> Sent from my iPhone
>>
>>> On Feb 16, 2018, at 7:45 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>
>>> I would like to simplify the upcoming R7 implementation of Declarative
>>> Services and drop the support for the proprietary extensions.
>>>
>>> Currently the implementation supports two additional namespaces for the
>>> component XML. The oldest one allows to define an updated method before
>>> it became part of the R4.2 release. So this has only been used
>>> temporarily until that release became official.
>>>
>>> Similar, there is a special namespace for the R4.3 release which can be
>>> used to indicate that the components might return additional service
>>> properties from the activate method. This feature has been discussed at
>>> that time in the OSGi expert group and was not rejected. While there
>>> might be some people using this, this is tied to the 4.3 specification.
>>> So as soon as you want to use R5 or R6 features or in the future R7
>>> features, this proprietary extension is not available to your component.
>>>
>>> My suggestion is we drop these things for the R7 version and simplify
>>> the implementation in some areas. If users want to use those features
>>> the R6 implementation is still there to be used and we can maintain it.
>>>
>>> Regards
>>> Carsten
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [SCR] Dropping the proprietary extensions for the R7 implementation

[Carsten Ziegeler <cz...@apache.org>]

My point is, if you use the extension you can't use a R5,R6 or R7
feature with that component.

Then we have things like FELIX-5775 where the code involved got so
complicated because of the proprietary support that I could find no way
to make this work when the extensions are used.

Regards

Carsten


David Jencks wrote
> As I recall, the behavior of all the extensions are available in the R6 version through the use of the ds ext annotations which get compiled into Felix namespace xml attributes by bnd. What exactly are you proposing removing?
> 
> I don’t think the top level xml namespaces offer much value but I’m not sure the code supporting them is complex enough to worry about. For the most part I think the behaviors of the extensions are fairly useful so I’d be reluctant to remove them. Making an osgi server that uses them not able to upgrade to r7 is a pretty big restriction.
> 
> David Jencks 
> 
> Sent from my iPhone
> 
>> On Feb 16, 2018, at 7:45 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> I would like to simplify the upcoming R7 implementation of Declarative
>> Services and drop the support for the proprietary extensions.
>>
>> Currently the implementation supports two additional namespaces for the
>> component XML. The oldest one allows to define an updated method before
>> it became part of the R4.2 release. So this has only been used
>> temporarily until that release became official.
>>
>> Similar, there is a special namespace for the R4.3 release which can be
>> used to indicate that the components might return additional service
>> properties from the activate method. This feature has been discussed at
>> that time in the OSGi expert group and was not rejected. While there
>> might be some people using this, this is tied to the 4.3 specification.
>> So as soon as you want to use R5 or R6 features or in the future R7
>> features, this proprietary extension is not available to your component.
>>
>> My suggestion is we drop these things for the R7 version and simplify
>> the implementation in some areas. If users want to use those features
>> the R6 implementation is still there to be used and we can maintain it.
>>
>> Regards
>> Carsten
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [SCR] Dropping the proprietary extensions for the R7 implementation

[David Jencks <da...@gmail.com>]

As I recall, the behavior of all the extensions are available in the R6 version through the use of the ds ext annotations which get compiled into Felix namespace xml attributes by bnd. What exactly are you proposing removing?

I don’t think the top level xml namespaces offer much value but I’m not sure the code supporting them is complex enough to worry about. For the most part I think the behaviors of the extensions are fairly useful so I’d be reluctant to remove them. Making an osgi server that uses them not able to upgrade to r7 is a pretty big restriction.

David Jencks 

Sent from my iPhone

> On Feb 16, 2018, at 7:45 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 
> I would like to simplify the upcoming R7 implementation of Declarative
> Services and drop the support for the proprietary extensions.
> 
> Currently the implementation supports two additional namespaces for the
> component XML. The oldest one allows to define an updated method before
> it became part of the R4.2 release. So this has only been used
> temporarily until that release became official.
> 
> Similar, there is a special namespace for the R4.3 release which can be
> used to indicate that the components might return additional service
> properties from the activate method. This feature has been discussed at
> that time in the OSGi expert group and was not rejected. While there
> might be some people using this, this is tied to the 4.3 specification.
> So as soon as you want to use R5 or R6 features or in the future R7
> features, this proprietary extension is not available to your component.
> 
> My suggestion is we drop these things for the R7 version and simplify
> the implementation in some areas. If users want to use those features
> the R6 implementation is still there to be used and we can maintain it.
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org