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

Expected names for id nodes #1688

Closed bjhargrave closed 13 years ago

bjhargrave commented 13 years ago

Original bug ID: BZ#1820 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>

The discussion was started as comments to Bug#1814. To summarize, we need to clarify what are expected and node names. Currently, they are:

- long value in range [0, Long.MAX_VALUE] - long value in range [Long.MIN_VALUE], Long.MAX_VALUE] NTT suggestions: " Secondly, I would like to discuss what to do with the system bundle. In OSGi, a. the Bundle ID "0" is assigned for the system bundle(framework). b. the Bundle ID is "long" in Java. There are three alternatives for "0" we can choose: [Alternative1] No change of RFC140. the PA will send the ParameterName corresponding the long value to the ACS, e.g. in GPNamesResponse. However the ACS might assume that it is invalid from the point of view of TR-069. It is out of scope of OSGi Spec, especially RFC149. [Alternative2] In RFC140, the bundle id node has the long value, at is incremented by one "0". (The node name of the system bundle will be "1".) [Alternative3] In RFC140 the bundle id node "0" will be kept. As Alternative1, ACS might assume that it is invalid from the point of view of TR-069. However, in addition, RFC140 will have special node for the system bundle. IMO, Alternative3 seems preferred. " I checked RFC-140 again. Those nodes are not enumerated i.e. the rule >= 1 should not be applied to them. IMO, we don't need to fix anything. The current RFC description is OK to me.
bjhargrave commented 13 years ago

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

I would like to fix all id node names. So, below is the full list:

  1. .../Framework/InstallBundle/
    • numeric character string
    • the range is unknown
  2. .../BundleControl/
    • bundle id
    • range [0, Long.MAX_VALUE]
  3. .../BundleState/
    • bundle id
    • range [0, Long.MAX_VALUE]
  4. .../PackageState/
    • continuous numerical string from 1
    • range is unknown
  5. .../ServiceState/
    • match the service id
    • range [[Long.MIN_VALUE, Long.MAX_VALUE]
  6. .../ServiceState//Properties/
    • numerical string from 1
    • the range is unknown
  7. .../Filters/
    • unique ID of Filters instance
    • the range is unknown
  8. .../BundleResources/
    • bundle id
    • range [0, Long.MAX_VALUE]
  9. .../BundleResources//
    • The name of should be put a mangled file name which is obtained by Uri#mangle(String).
    • no range
bjhargrave commented 13 years ago

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

[Alternative3] In RFC140 the bundle id node "0" will be kept. As Alternative1, ACS might assume that it is invalid from the point of view of TR-069. However, in addition, RFC140 will have special node for the system bundle.

Let me explain Alternative3 taking an example of "../Framework/BundleControl/":

In that case, RFC149 will keep the interior node of "../Framework/BundleControl/0" for the system bundle. In addition, RFC149 will have new interior node of "../Framework/SystemBundleControl", which is just an alias of "../Framework/BundleControl/0".

In case that TR-069 is used, ACS can control the lifecycle of the system bundle by using "../Framework/SystemBundleControl" subtree.

Now, it is time to vote.

NTT votes for Alternative3, while ProSyste votes for Alternative2. We need to vote by other REG members (DT, 2Wire), immediately.

bjhargrave commented 13 years ago

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

[Alternative3] In RFC140 the bundle id node "0" will be kept. As Alternative1, ACS might assume that it is invalid from the point of view of TR-069. However, in addition, RFC140 will have special node for the system bundle.

Let me explain Alternative3 taking an example of "../Framework/BundleControl/":

In that case, RFC149 will keep the interior node of "../Framework/BundleControl/0" for the system bundle. In addition, RFC149 will have new interior node of "../Framework/SystemBundleControl", which is just an alias of "../Framework/BundleControl/0".

In case that TR-069 is used, ACS can control the lifecycle of the system bundle by using "../Framework/SystemBundleControl" subtree. Note that PA will apply "table rule" (TR-149, 6.6, Translation on node names) on ../Framework/BundleControl/0. In this case, ACS will receive the system bundle in format ../Framework/BundleControl/< anyint>=1 >. < anyint>=1 > - 1, 2, 3, 4,... That's the real problem. The system bundle identifier will occupy another bundle id.

bjhargrave commented 13 years ago

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Evgeni, I understand what you mean and agree.

So unfortunately, Alternative 2 is only way to choose.

[Alternative3] In RFC140 the bundle id node "0" will be kept. As Alternative1, ACS might assume that it is invalid from the point of view of TR-069. However, in addition, RFC140 will have special node for the system bundle.

Let me explain Alternative3 taking an example of "../Framework/BundleControl/":

In that case, RFC149 will keep the interior node of "../Framework/BundleControl/0" for the system bundle. In addition, RFC149 will have new interior node of "../Framework/SystemBundleControl", which is just an alias of "../Framework/BundleControl/0".

In case that TR-069 is used, ACS can control the lifecycle of the system bundle by using "../Framework/SystemBundleControl" subtree. Note that PA will apply "table rule" (TR-149, 6.6, Translation on node names) on ../Framework/BundleControl/0. In this case, ACS will receive the system bundle in format ../Framework/BundleControl/< anyint>=1 >. < anyint>=1 > - 1, 2, 3, 4,... That's the real problem. The system bundle identifier will occupy another bundle id.

bjhargrave commented 13 years ago

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

The issue of this Bug is updated in RFC140 Ver.1.11.