rfc-241 (Feature) - json structure and comment

[bjhargrave]

Original bug ID: BZ#234
From: [email protected]
Reported version: unspecified

[bjhargrave]

Comment author: [email protected]

It would be nice to have the same ways to Comment in Features and Configurator.

When reading rfc 241, I can see in the Example that an key that starts(?) with a # is an comment:

{

"# some" : "comment",

"#" : "key starts with hast es enough",

"key" : "value"
}

The spec of the Configurator:

{
// Comment

/*
* More comments
*/

"key" : "value"
}

1. It may help to add some Comments in the form of JSMin (The JavaScript Minifier) comments ( // and /* */ ) to your example to point out that this is also valid.

2. It would be nice to have more information about - how to do comment

´´´
"#" : "Is it only Key must start with an #?",
"#" : "is having same key twice also okay?",
"# foo" : "# bar is okay"
"#": null;
"#": { "fooComment", "barComment"};

"#": ["and",
"this",
"?"],
´´´

3. Does that mean, that Service-Properties/Configurations with the name "#" couldn't be set using the features configuration? Or will every comment in the configurator section be handled as an component-property?

4. the Example is not a valid json. is that correct?

"sql-init|TEXT:true": {
"# create some database tables for this feature",
"CREATE TABLE FOO (...)",
"CREATE TABLE BAR (...)"
},

5. to declare the type of Extensibility you can use a |. to declate a data-type in configurator you have to use a : it may should be the same separator in boths.

6. is it correct that the ":true" behind the Extensibilit-Type is the optional/mandantory flag for the Extensibility.

[bjhargrave]

Comment author: @cziegeler

Yes, it makes sense to support the same way of commenting. We probably will remove the usage of "#" for comments and allow the same comments as in the configurator spec.

[bjhargrave]

Comment author: @bosschaert

Hi Stefan,

Thanks for the feedback!

Yes, I agree that JSMin-style like used in the configurator spec makes more sense. This will also allow for the embedding of configurator configurations in the feature model.

On the extensions, I have since updated the RFC to use a more JSON-native approach to extensions.

You can find the updated RFC at https://github.com/osgi/design/blob/master/rfcs/rfc0241/rfc-0241-Features.pdf

[bjhargrave]

Comment author: @bosschaert

Note that the updated RFC now contains a new section on comments (section 5.4).