Skip to content
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.

rfc-241 (Feature) - json structure and comment #42

Open
bjhargrave opened this issue Jul 31, 2019 · 4 comments
Open

rfc-241 (Feature) - json structure and comment #42

bjhargrave opened this issue Jul 31, 2019 · 4 comments
Assignees
Labels
publiccomment Public comment

Comments

@bjhargrave
Copy link
Member

Original bug ID: BZ#234
From: stbischof@bipolis.org
Reported version: unspecified

@bjhargrave
Copy link
Member Author

Comment author: stbischof@bipolis.org

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",
"?"],
´´´

  1. 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?

  2. 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 (...)"
},
  1. 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.

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

@bjhargrave
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

Comment author: @bosschaert

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

@bjhargrave bjhargrave added the publiccomment Public comment label May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
publiccomment Public comment
Projects
None yet
Development

No branches or pull requests

2 participants