search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

Versioning of Residential Management Objects #1665

Closed bjhargrave closed 13 years ago

bjhargrave commented 13 years ago

Original bug ID: BZ#1797 From: Evgeni Grigorov <e.grigorov@prosyst.com> Reported version: R4 V4.3

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

According to Bug#398, the version of each OSGi Mobile Management Object is provided with the help of the root node type. That's fine for protocols like OMA DM, where the type can be directly explored. For TR related model, the Management Object version should be a part of the DeviceSummary node value with own string representation. It needs to define the strict rules for root node type. For example:

::= /./[/]* ::= “reversed internet domain name” ::= [1-9][0-9]* ::= 0 | [1-9][0-9]* ::= alphanum Those rules provide an easy access to the name, version and is compatible with the available OSGi Mobile Objects. It should be up to the implementation to decide when and how will read that type. A few possible solutions: -- on the first node value read - note, that the tree can be locked by another session. -- on framework started event - will break the plug-in lazy start The suggestions for the root node types are: .../OSGi/ -> org.osgi/1.0/OSGiManagementObject .../OSGi//Framework -> org.osgi/1.0/FrameworkManagementObject .../OSGi//BundleState -> org.osgi/1.0/BundleStateManagementObject .../OSGi//ServiceState -> org.osgi/1.0/ServiceStateManagementObject .../OSGi//PackageState -> org.osgi/1.0/PackageStateManagementObject .../OSGi//BundleResources -> org.osgi/1.0/BundleResourcesManagementObject .../OSGi//Filters -> org.osgi/1.0/FiltersManagementObject The representation in the DeviceSummary should be: ....,OSGi:1.0[1](Baseline:1),OSGi.1.Framework:1.0[1](Baseline:1),...
bjhargrave commented 13 years ago

Comment author: jblackford@2wire.com

BBF has deprecated the DeviceSummary parameter and the new Device:2 (TR-181 Issue 2) Data Model doesn't even include the parameter. The replacement mechanism is the CWMP-DM and CWMP-DT XML Schema documents (described in TR-106 Amendment 4) and the SupportedDataModel table (described in TR-157 Amendment 2).

Based on that information, I don't think that we need to worry about mapping OSGi data model names into the BBF DeviceSummary names.

I'm not sure that we currently discuss the CMWP-DM, CWMP-DT, and SupportedDataModel table within any of the RFCs, but I'm not sure we need to at this point. These concepts could be implementation details or left for another revision of RFC 149.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

BBF has deprecated the DeviceSummary parameter and the new Device:2 (TR-181 Issue 2) Data Model doesn't even include the parameter. The replacement mechanism is the CWMP-DM and CWMP-DT XML Schema documents (described in TR-106 Amendment 4) and the SupportedDataModel table (described in TR-157 Amendment 2).

Based on that information, I don't think that we need to worry about mapping OSGi data model names into the BBF DeviceSummary names.

I'm not sure that we currently discuss the CMWP-DM, CWMP-DT, and SupportedDataModel table within any of the RFCs, but I'm not sure we need to at this point. These concepts could be implementation details or left for another revision of RFC 149. We need a mechanism to provide management object versions to ACS. The suggestion tries to resolve that issue.

Currently, we have DeviceSummary, it is a nice place to put the versions. The next spec version can use the new XML document, then the version can be placed there.

bjhargrave commented 13 years ago

Comment author: wlupton@2wire.com

Currently, we have DeviceSummary, it is a nice place to put the versions. The next spec version can use the new XML document, then the version can be placed there.

Whether or not we have DeviceSummary depends on which data model is being supported. If Device:2 or a non-BBF data model we do not have DeviceSummary.

Given that DeviceSummary is deprecated, and is not BBF's approach for describing the supported data model, I don't think that our new REG specs should describe it.

Also, please note that your proposed usage of DeviceSummary is not consistent with the BBF intent:

"The DeviceSummary is defined as a list that includes the Root Object followed by all Service Object instances (or support for a Service Object type if no instances are currently present). For each of these objects, the DeviceSummary specifies the version of the object, the associated instance number used to identify the specific object instance, and a list of the supported profiles for that object"

In your example:

....,OSGi:1.01,OSGi.1.Framework:1.01,...

"OSGi" and "OSGi.1.Framework" are not Root or Service Object names. In fact the only valid Root Object names are "Device" and "InternetGatewayDevice", and Service Object names are the names of objects that could validly exist as children of the .Services.

So I think that there would in any case be more work in order to work out how best to use DeviceSummary.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Currently, we have DeviceSummary, it is a nice place to put the versions. The next spec version can use the new XML document, then the version can be placed there.

Whether or not we have DeviceSummary depends on which data model is being supported. If Device:2 or a non-BBF data model we do not have DeviceSummary.

Given that DeviceSummary is deprecated, and is not BBF's approach for describing the supported data model, I don't think that our new REG specs should describe it. That question is old enough. The DeviceSummary is deprecated with the note: " Therefore the value of DeviceSummary MAY be an empty string if (and only if) the SupportedDataModel object is supported. " That means, CPE can support both of them SupportedDataModel object and DeviceSummary, because of "MAY".

I'll post a separate issue about the obsolete data model.

Also, please note that your proposed usage of DeviceSummary is not consistent with the BBF intent:

"The DeviceSummary is defined as a list that includes the Root Object followed by all Service Object instances (or support for a Service Object type if no instances are currently present). For each of these objects, the DeviceSummary specifies the version of the object, the associated instance number used to identify the specific object instance, and a list of the supported profiles for that object"

In your example:

....,OSGi:1.01,OSGi.1.Framework:1.01,...

"OSGi" and "OSGi.1.Framework" are not Root or Service Object names. In fact the only valid Root Object names are "Device" and "InternetGatewayDevice", and Service Object names are the names of objects that could validly exist as children of the .Services. I known about it. The example is intentionally in this format. The reason is very simple. OSGi RMT is constructed by:

  1. a few OSGi framewokrs - .../OSGi/1, .../OSGi/2 - We need to specify a version to all of them.
  2. Each OSGi framework contains different management object. Some of them are optional with its own version. To summarize, CPE needs to provide version for:
    • OSGi subtree
    • Framework Object
    • ... all objects from the fist comment So I think that there would in any case be more work in order to work out how best to use DeviceSummary. You are right. I hope that the start was made.
bjhargrave commented 13 years ago

Comment author: hkirksey@motive.com

I think we've got a number of issues here:

  1. DeviceSummary has been deprecated by BBF, so if we try to build any sort of solution using it, it won't be future proof, supported by devices, or something that ACS vendors are investing in.

  2. Because this would be breaking the defined rules for DeviceSummary, ACSes that actually still do make use of this parameter would not be able to parse the information without changing their implementation, which they're unlikely to do (especially since this would be a change to a generic parameter specifically for OSGi and since the parameter is deprecated).

  3. DeviceSummary was not designed to communicate versioning information, so this really isn't an appropriate usage of it; ACSes don't currently behave in this way so implementations would have to be changed to do this sort of processing (which is unlikely for the reasons I've already described).

Any solution that we come up with to this problem should make use of the DT mechanism and the SupportedDataModel table. BBF really spent a great deal of time thinking about DeviceSummary and the best way to communicate information about the data model a device supports and decided that DeviceSummary wasn't adequate or appropriate. That's why we deprecated the parameter and wrote the DT schema in TR-106. So I think we should go with the best practices and state of the art rather than using something that's already been deemed insufficient in a non-standard way.

Note that since we haven't really yet included the concept of DT schema in any of our RFCs, I'd be inclined to suggest that at this point we may just want to include DT support and related discussion on the list of items for the next release.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I think we've got a number of issues here:

  1. DeviceSummary has been deprecated by BBF, so if we try to build any sort of solution using it, it won't be future proof, supported by devices, or something that ACS vendors are investing in. Always true

  2. Because this would be breaking the defined rules for DeviceSummary, ACSes that actually still do make use of this parameter would not be able to parse the information without changing their implementation, which they're unlikely to do (especially since this would be a change to a generic parameter specifically for OSGi and since the parameter is deprecated).

  3. DeviceSummary was not designed to communicate versioning information, so this really isn't an appropriate usage of it; ACSes don't currently behave in this way so implementations would have to be changed to do this sort of processing (which is unlikely for the reasons I've already described). If DeviceSummary is not designed to provide versioning information, the idea is broken.

Any solution that we come up with to this problem should make use of the DT mechanism and the SupportedDataModel table. BBF really spent a great deal of time thinking about DeviceSummary and the best way to communicate information about the data model a device supports and decided that DeviceSummary wasn't adequate or appropriate. That's why we deprecated the parameter and wrote the DT schema in TR-106. So I think we should go with the best practices and state of the art rather than using something that's already been deemed insufficient in a non-standard way.

Note that since we haven't really yet included the concept of DT schema in any of our RFCs, I'd be inclined to suggest that at this point we may just want to include DT support and related discussion on the list of items for the next release. It's OK to me. At least, I would like to have a version support to all OSGi management objects. To summarize my suggestion:

  1. We can specify versions to all OSGi management objects. For backward compatibility with OSGi Mobile management tree, they can be set as root node types (see Comment#1).
  2. How those versions will be provided to ACS will be postponed to the next release. Is it OK to all?
bjhargrave commented 13 years ago

Comment author: hkirksey@motive.com

Evegeni,

That's ok for me. Just to make sure we don't lose track of this, could I ask Kai and/or Andreas to capture the issue of communicating versioning information and making use of CWMP-DT as possible topics for next release (the RFC on additional TR-069 mapping I'd guess). Thanks!

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I would like to provide more details about the versioning and the covered nodes. So, I'll be sure that the RMT version is well defined:

  1. .../OSGi//Framework -> org.osgi/1.0/FrameworkManagementObject
    • that version will track: -- .../OSGi//Framework -- and its children
  2. .../OSGi//BundleState -> org.osgi/1.0/BundleStateManagementObject
    • that version will track: -- .../OSGi//BundleState -- and its children
  3. .../OSGi//ServiceState -> org.osgi/1.0/ServiceStateManagementObject
    • that version will track: -- .../OSGi//ServiceState -- and its children
  4. .../OSGi//PackageState -> org.osgi/1.0/PackageStateManagementObject
    • that version will track: -- .../OSGi//PackageState -- and its children
  5. .../OSGi//BundleResources -> org.osgi/1.0/BundleResourcesManagementObject
    • that version will track: -- .../OSGi//BundleResources -- and its children
  6. .../OSGi//Filters -> org.osgi/1.0/FiltersManagementObject
    • that version will track: -- .../OSGi//Filters -- and its children
  7. Finally, I'll not provide a version, but a question with possible answers. How to track the version of nodes: -- .../OSGiNumberOfEntries -- .../OSGi -- .../OSGi/ -- .../OSGi//Local -- .../OSGi//BundleStateNumberOfEntries -- .../OSGi//ServiceStateNumberOfEntries -- .../OSGi//PackageStateNumberOfEntries [Answer 1] The version can be specified as a type of .../OSGi/. The major negative is that .../OSGi/ cannot be scaffold node. There must be a plug-in, which will return the correct version. That means that Framework, BundleState, ... can be added only with predefined mount points. It's not very flexible, because it is hard to add new management objects like Configuration, ... [Answer 2] The version can be specified as a type of .../OSGi//Local. The major negative is that the node is leaf and the type should be data MIME type. [Answer 3] The version can be specified as a type of a new internal node .../OSGi//Version. The major negative is that we provide a new node only to specify the version. I prefer [Answer 1], but I would like to improve the flexibility. What do you think to allow wildcard ('') as a last element in the mount point Uri. For example, DP can be registered with: dataRootURIs = {./Device/Services/OSGi/#} - the runtime it will be ./Device/Services/OSGi/1 or something like that mountPoint = - that means that plug-in with any name can be mounted to /Services/OSGi/1

Ikuo, William, could you check and comment?

bjhargrave commented 13 years ago

Comment author: jblackford@2wire.com

Version is defined as: "Version – (int) Version number, which must start at 0, incremented after every modification (for both a leaf and an interior node) modulo 0x10000. Changes to the value or any of the properties (including ACLs), or adding/deleting nodes, are considered changes. The getNode- Version(String) method returns this version; the value is read-only. In certain cases, the underlying data structure does not support change notifications or makes it difficult to support versions. This property is optional depending on the node’s implementation."

So I'm confused as to why version tracks a node and its children since the nodes you are listing are static (cardinality 1) nodes and can't be added or deleted.

I would like to provide more details about the versioning and the covered nodes. So, I'll be sure that the RMT version is well defined:

  1. .../OSGi//Framework -> org.osgi/1.0/FrameworkManagementObject
    • that version will track: -- .../OSGi//Framework -- and its children
  2. .../OSGi//BundleState -> org.osgi/1.0/BundleStateManagementObject
    • that version will track: -- .../OSGi//BundleState -- and its children
  3. .../OSGi//ServiceState -> org.osgi/1.0/ServiceStateManagementObject
    • that version will track: -- .../OSGi//ServiceState -- and its children
  4. .../OSGi//PackageState -> org.osgi/1.0/PackageStateManagementObject
    • that version will track: -- .../OSGi//PackageState -- and its children
  5. .../OSGi//BundleResources -> org.osgi/1.0/BundleResourcesManagementObject
    • that version will track: -- .../OSGi//BundleResources -- and its children
  6. .../OSGi//Filters -> org.osgi/1.0/FiltersManagementObject
    • that version will track: -- .../OSGi//Filters -- and its children
  7. Finally, I'll not provide a version, but a question with possible answers. How to track the version of nodes: -- .../OSGiNumberOfEntries -- .../OSGi -- .../OSGi/ -- .../OSGi//Local -- .../OSGi//BundleStateNumberOfEntries -- .../OSGi//ServiceStateNumberOfEntries -- .../OSGi//PackageStateNumberOfEntries [Answer 1] The version can be specified as a type of .../OSGi/. The major negative is that .../OSGi/ cannot be scaffold node. There must be a plug-in, which will return the correct version. That means that Framework, BundleState, ... can be added only with predefined mount points. It's not very flexible, because it is hard to add new management objects like Configuration, ... [Answer 2] The version can be specified as a type of .../OSGi//Local. The major negative is that the node is leaf and the type should be data MIME type. [Answer 3] The version can be specified as a type of a new internal node .../OSGi//Version. The major negative is that we provide a new node only to specify the version. I prefer [Answer 1], but I would like to improve the flexibility. What do you think to allow wildcard ('') as a last element in the mount point Uri. For example, DP can be registered with: dataRootURIs = {./Device/Services/OSGi/#} - the runtime it will be ./Device/Services/OSGi/1 or something like that mountPoint = - that means that plug-in with any name can be mounted to /Services/OSGi/1 JB: It seems like all three possible answers have drawbacks so could we take the "This property is optional depending on the node’s implementation" road and have it always be a 0 version?

Ikuo, William, could you check and comment?

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Version is defined as: "Version – (int) Version number, which must start at 0, incremented after every modification (for both a leaf and an interior node) modulo 0x10000. Changes to the value or any of the properties (including ACLs), or adding/deleting nodes, are considered changes. The getNode- Version(String) method returns this version; the value is read-only. In certain cases, the underlying data structure does not support change notifications or makes it difficult to support versions. This property is optional depending on the node’s implementation."

So I'm confused as to why version tracks a node and its children since the nodes you are listing are static (cardinality 1) nodes and can't be added or deleted. I can see your confusion. The big difference is that the issue is about version of the management object, not about a specific node. DmtSession.getNodeVersion(String) works only on a given node. OSGi DMT tracks the management object version as a type of the root node (see Bug#398).

I would like to provide more details about the versioning and the covered nodes. So, I'll be sure that the RMT version is well defined:

  1. .../OSGi//Framework -> org.osgi/1.0/FrameworkManagementObject
    • that version will track: -- .../OSGi//Framework -- and its children
  2. .../OSGi//BundleState -> org.osgi/1.0/BundleStateManagementObject
    • that version will track: -- .../OSGi//BundleState -- and its children
  3. .../OSGi//ServiceState -> org.osgi/1.0/ServiceStateManagementObject
    • that version will track: -- .../OSGi//ServiceState -- and its children
  4. .../OSGi//PackageState -> org.osgi/1.0/PackageStateManagementObject
    • that version will track: -- .../OSGi//PackageState -- and its children
  5. .../OSGi//BundleResources -> org.osgi/1.0/BundleResourcesManagementObject
    • that version will track: -- .../OSGi//BundleResources -- and its children
  6. .../OSGi//Filters -> org.osgi/1.0/FiltersManagementObject
    • that version will track: -- .../OSGi//Filters -- and its children
  7. Finally, I'll not provide a version, but a question with possible answers. How to track the version of nodes: -- .../OSGiNumberOfEntries -- .../OSGi -- .../OSGi/ -- .../OSGi//Local -- .../OSGi//BundleStateNumberOfEntries -- .../OSGi//ServiceStateNumberOfEntries -- .../OSGi//PackageStateNumberOfEntries [Answer 1] The version can be specified as a type of .../OSGi/. The major negative is that .../OSGi/ cannot be scaffold node. There must be a plug-in, which will return the correct version. That means that Framework, BundleState, ... can be added only with predefined mount points. It's not very flexible, because it is hard to add new management objects like Configuration, ... [Answer 2] The version can be specified as a type of .../OSGi//Local. The major negative is that the node is leaf and the type should be data MIME type. [Answer 3] The version can be specified as a type of a new internal node .../OSGi//Version. The major negative is that we provide a new node only to specify the version. I prefer [Answer 1], but I would like to improve the flexibility. What do you think to allow wildcard ('') as a last element in the mount point Uri. For example, DP can be registered with: dataRootURIs = {./Device/Services/OSGi/#} - the runtime it will be ./Device/Services/OSGi/1 or something like that mountPoint = - that means that plug-in with any name can be mounted to /Services/OSGi/1 JB: It seems like all three possible answers have drawbacks so could we take the "This property is optional depending on the node’s implementation" road and have it always be a 0 version? The most important versions are for Framework, BundleState, ... It's acceptable to drop framework instance version, if we don't accept '*' as a last element in the mount point path.

Ikuo, William, could you check and comment?

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

[01.12.2010] REG Conference Call REG agreed that the most important management objects are: Framework, BundleState, ServiceState, PackageState, BundleResources and Filters. The upcoming release will contain only their versions. The versions will be specified as in Comment#8. There will be another issue for the next release to resolve how CPE will provide those versions to ACS. Currently, it will be implementation decision.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Bug#1812 will continue the discussion in the next specification release.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Depends on Bug#1813, but we can resolve Comment#8, point 7. If we support '*' as a last mount point path element. We can wait to see its resolution.

bjhargrave commented 13 years ago

Comment author: Shigekuni Kondo <kondo.shigekuni@lab.ntt.co.jp>

The agreement in this Bug is added to RFC140 Ver.2.0.