Issue 6587: Configuration interface (sdo-pim-psm-ftf) Source: (, ) Nature: Revision Severity: Minor Summary: The Configuration interface provides operations to ‘set’ or ‘remove’ ‘device’ or ‘service’ profiles (setDeviceProfile(…), addServiceProfile(…), removeDeviceProfile(), removeServiceProfile(…)). We can implement them without problem but the problem is the real implication or the usage of such operations. An SDO may represent a device. We must clearly define in what circumstances do we need to remove the device profile or set the new profile. Similarly an SDO may provide one or more services. How can it provide new services in reality if the device it is representing is the same? How is this new service instantiated? Let’s look at each of these operations in more detail: • setDeviceProfile(…) o Overwrite old DeviceProfile with the new Device Profile. o What else should be done to reflect the changes in the DeviceProfile? • removeDeviceProfile(…) o Removes the existing DeviceProfile o What else should be done to reflect that there is no DeviceProfile? For example if the SDO represents ‘TV’, is this method invoked when real hardware device (‘TV’) is temporarily not available? Moreover, what does it mean when there is no ‘DeviceProfile’ but the SDO represents ‘TV’? Does it still continue to provide services it was providing? • addServiceProfile(…) o Adds new service profile o Instantiate the service An SDO represents a device (eg. ‘TV’) or a service. A ‘TV’ or any other SDOs most probably will not have to provide additional service during its runtime. • removeServiceProfile(…) o stop the service o remove service profile o What else does it need to do? Should it send message to all SDOs that are using this service? Most likely SDO can only internally invoke such operations when required. Other SDO should not be allowed to invoke such operations. Resolution: Revised Text: Actions taken: November 10, 2003: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 10 Nov 2003 19:54:17 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ken-ichiroh Kawakami Company: Hitachi Ltd,. mailFrom: ken-ichi@sdl.hitachi.co.jp Notification: Yes Specification: PIM and PSM for SDO Section: PIM FormalNumber: dtc/03-09-01 Version: 03-09-01 RevisionDate: 03-09-03 Page: 2-11 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description The Configuration interface provides operations to ‘set’ or ‘remove’ ‘device’ or ‘service’ profiles (setDeviceProfile(…), addServiceProfile(…), removeDeviceProfile(), removeServiceProfile(…)). We can implement them without problem but the problem is the real implication or the usage of such operations. An SDO may represent a device. We must clearly define in what circumstances do we need to remove the device profile or set the new profile. Similarly an SDO may provide one or more services. How can it provide new services in reality if the device it is representing is the same? How is this new service instantiated? Let’s look at each of these operations in more detail: • setDeviceProfile(…) o Overwrite old DeviceProfile with the new Device Profile. o What else should be done to reflect the changes in the DeviceProfile? • removeDeviceProfile(…) o Removes the existing DeviceProfile o What else should be done to reflect that there is no DeviceProfile? For example if the SDO represents ‘TV’, is this method invoked when real hardware device (‘TV’) is temporarily not available? Moreover, what does it mean when there is no ‘DeviceProfile’ but the SDO represents ‘TV’? Does it still continue to provide services it was providing? • addServiceProfile(…) o Adds new service profile o Instantiate the service An SDO represents a device (eg. ‘TV’) or a service. A ‘TV’ or any other SDOs most probably will not have to provide additional service during its runtime. • removeServiceProfile(…) o stop the service o remove service profile o What else does it need to do? Should it send message to all SDOs that are using this service? Most likely SDO can only internally invoke such operations when required. Other SDO should not be allowed to invoke such operations.