Hi, here is a proposal about implementing the features below: * GetSearchCapabilities() * GetSortCapabilities() * GetSortExtensionCapabilities() * GetFeatureList() * dlna:X_DLNACAP New properties will be added to com.intel.UPnP.MediaDevice interface, to exposes information about device capabilities and features. These new properties are described below: |-----------------------------------------------------------------------------| | Name | Type | m/o* | Description | |-----------------------------------------------------------------------------| | SearchCap | as | m | List of property names that can be used | | | | | in search queries | |-----------------------------------------------------------------------------| | SortCap | as | m | List of property names that can use to |

| | | | sort Search() or Browse() action results. | |-----------------------------------------------------------------------------| | SortExtCap | as | o | list of sort modifiers that can use to |

| | | | sort Search() or Browse() action results. | |-----------------------------------------------------------------------------| | FeatureList |a{s(as)}| m | List of features supported by this | | | | | ContentDirectory service. | |-----------------------------------------------------------------------------| | DLNACap | as | o | List of Capability ID supported by the |

| | a{sv} | | device. | |-----------------------------------------------------------------------------|

There is an option for the type of DLNACap: a{sv}. Some capabilities are builded with data value, like the example below: srs-retention-capability-id = “srs-rt-retention-period-” duration duration = <ui4 value> | “infinity” srs-rt-retention-period-100 srs-rt-retention-period-infinity So we can extact the value from the capability id. We can do this for all known capabilities, but not for vendor specific ones. In this case, the raw capability id will be returned. I think the option a{sv} is better than as.

Any comments welcome. -- Ludovic Ferrandis Open Source Technology Center --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros _______________________________________________ dLeyna mailing list dLeyna(a)lists.01.org https://lists.01.org/mailman/listinfo/dleyna

Updated proposal. See below [snip] ... I would add an 's' onto the names of the properties that end in Cap, e.g., SearchCaps. In spec doc they use FeatureList. Should we also change it to FeatureSList?

We should specify that SearchCap and SortCap will be empty if the DMS does not support Searching or Sorting. We need to take particular care with SortExtCap: 1. The code in sort.c that maps between MediaServer2Spec properties and UPNP properties only allows for + and -. This code will need to be modified to allow extended sort operators to be passed to the msu. 2. If I understand correctly SortExtCap will only appear if GetSortExtensionCapabilities is implemented by the server. Is this correct? Yes. SortExtCap will be empty if not supported.

Assuming that this is the case, I would make FeatureList optional. Although this method is compulsory in UPnP Av2 and 3 it does not appear in UPnP Av1 so it's best to make it optional. ok. Should the signature for feature list be a{ss(as)} rather than a{s(as)}? Note the extra 's' for the version number. ok. |------------------------------------------------------------------------------| | Name | Type | m/o* | Description | |------------------------------------------------------------------------------| | SearchCaps | as | m | List of property names that can be used | | | | | in search queries. | | | | | Empty if not supported by the device. | |------------------------------------------------------------------------------| | SortCaps | as | m | List of property names that can used to | | | | | sort Search() or Browse() action results. | | | | | Empty if not supported by the device. | |------------------------------------------------------------------------------| | SortExtCaps | as | o | list of sort modifiers that can used to | | | | | sort Search() or Browse() action results. | | | | | Empty if not supported by the device. | |------------------------------------------------------------------------------| | FeatureList |a{ss(as)}| o | List of features supported by this | | | | | ContentDirectory service. | |------------------------------------------------------------------------------| | DLNACaps | a{sv} | o | List of Capability IDs supported by the | | | | | device. | |------------------------------------------------------------------------------| One final comment. Implementing the optional capabilities and features as properties introduces a bit more work for you in the short term, as it will require changes to the code that retrieves device properties. Currently all this information is retrieved synchronously (msu_props_add_device) but for these new properties you will need to invoke UPnP functions which must be done asynchronously. This is not a big deal but it will complicate the code a little. Just wanted to point this out. I should also say, that I agree that properties are the way to go here. [snip] -- Ludovic Ferrandis Open Source Technology Center --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros