8:16 p.m.
Hi,
I'm looking to add new functions or new properties in
com.intel.UPnP.MediaDevice interface to manage the features below:
GetSearchCapabilities()
GetSortCapabilities()
GetSortExtensionCapabilities()
GetFeatureList()
DLNA_CAPS
In props.h we don't list all existing properties defined in
ContentDirectory service:2, Appendix B, page 114 gor upnp: (base
properties) and res: (resource properties).
There is a Class Properties Overview (Table C-1: page 148) that defined 132
properties.
We also need to translate upnp/dlane properies name to MediaServerSpec2
names.
1 - Should we manage only properties defined in MediaServerSpec2 and drop
other properties send by the server?
-> I think we should manage all properties
2 - How to manage properties not defined in MediaServerSpec2?
-> Add them as _ext?
3 - Should we add all defined properties by upnp in props.h?
-> I think we should. It will be done.
4 - Why msu_upnp_prop_mask is a bit field? I don't think we could have a
property with multiple property name. And it will be difficult to manage
132 properties.
-> Convert it to integer enum and rename it (remove _mask)
5 - How to manage Vendor-defined values (for Feature list, or for
property's value)
a - We could define a single const "VENDOR-DEFINED" mask for all
features/property's values
b - Define a mask by feature/property value (like FEATURE-VENDORE-DEFINED,
UPNP-CLASS-VENDOR-DEFINED) etc... The same assigned to all vendor defined
property values
c - Define a unique value for each vendor-specific property value.
UPNP-CLASS-VENDOR-DEFINED-X
If solution 'a' is enough, I'll go with it.
6 - What about vendor defined properties?
-> Same behavior as '5'?
--
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
7:01 p.m.
Hi Ludovic,
On Tue, 2012-08-14 at 12:16 +0200, Ferrandis, Ludovic wrote:
Hi,
I'm looking to add new functions or new properties in
com.intel.UPnP.MediaDevice interface to manage the features below:
GetSearchCapabilities()
GetSortCapabilities()
GetSortExtensionCapabilities()
GetFeatureList()
DLNA_CAPS
In props.h we don't list all existing properties defined in
ContentDirectory service:2, Appendix B, page 114 gor upnp: (base
properties) and res: (resource properties).
There is a Class Properties Overview (Table C-1: page 148) that
defined 132 properties.
We also need to translate upnp/dlane properies name to
MediaServerSpec2 names.
1 - Should we manage only properties defined in MediaServerSpec2 and
drop other properties send by the server?
-> I think we should manage all properties
I disagree. In general I think we should only manage properties that we
actually support. I don't think we want to fill our code full of
properties that we don't currently and may never use. It will make the
code base bigger and more difficult to maintain.
2 - How to manage properties not defined in MediaServerSpec2?
-> Add them as _ext?
Currently we have three different types of properties in prop.h.
MediaServer2Spec properties, MediaServer2Spec extensions
(MSU_INTERFACE_PROP_URL and MSU_INTERFACE_PROP_RESOURCES) and properties
defined on other interfaces, e.g., com.intel.UPnP.MediaDevice. The
names of all these properties are defined in props.h. The properties
are separated from each other by chunks of white space but not via
naming convention. It's probably a good idea to introduce a naming
convention to clearly identify the properties, as you suggest, e.g.
MSU_INTERFACE_PROP_MS2_EXT_RESOURCES
MSU_INTERFACE_PROP_MS2_MIME_TYPE
MSU_INTERFACE_PROP_DEV_LOCATION
We could use a similar naming convention in msu_upnp_props_mask enum, e.g.,
MSU_UPNP_MASK_PROP_MS2_PARENT
MSU_UPNP_MASK_PROP_MS2_EXT_URL
3 - Should we add all defined properties by upnp in props.h?
-> I think we should. It will be done.
Again, I disagree. Let's just add what is needed.
4 - Why msu_upnp_prop_mask is a bit field? I don't think we could have
a property with multiple property name. And it will be difficult to
manage 132 properties.
-> Convert it to integer enum and rename it (remove _mask)
It won't need to manage 132 properties. This mask is only used for the
MediaServer2Spec properties we use and our extensions. Currently, there
are only 24 of these. We may need to add a few more properties in the
future but we are unlikely to reach anywhere near 132.
A bit field is used to implement a crude, but fast integer set. It allows us to
efficiently remove duplicates in the filter array passed to the Search
and ListChildren commands. It also allows us to quickly exclude
properties returned by the server that the client does not wish to
receive.
5 - How to manage Vendor-defined values (for Feature list, or for
property's value)
a - We could define a single const "VENDOR-DEFINED" mask for all
features/property's values
b - Define a mask by feature/property value (like
FEATURE-VENDORE-DEFINED, UPNP-CLASS-VENDOR-DEFINED) etc... The same
assigned to all vendor defined property values
c - Define a unique value for each vendor-specific property value.
UPNP-CLASS-VENDOR-DEFINED-X
If solution 'a' is enough, I'll go with it.
Do we need to manage these values at all? Can we not just pass the values we get
from UPnP directly to our clients? This is what happens to most property values
at the moment, with some notable exceptions, e.g., Type, that we map for MediaServer2Spec
compatibility. What particular use case did you have in mind?
6 - What about vendor defined properties?
-> Same behavior as '5'?
--
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
8:23 p.m.
On Thu, Aug 16, 2012 at 11:01 AM, Mark D Ryan
<mark.d.ryan(a)linux.intel.com>wrote:
Hi Ludovic,
On Tue, 2012-08-14 at 12:16 +0200, Ferrandis, Ludovic wrote:
> Hi,
>
> I'm looking to add new functions or new properties in
> com.intel.UPnP.MediaDevice interface to manage the features below:
>
>
> GetSearchCapabilities()
> GetSortCapabilities()
> GetSortExtensionCapabilities()
> GetFeatureList()
>
> DLNA_CAPS
>
> In props.h we don't list all existing properties defined in
> ContentDirectory service:2, Appendix B, page 114 gor upnp: (base
> properties) and res: (resource properties).
> There is a Class Properties Overview (Table C-1: page 148) that
> defined 132 properties.
> We also need to translate upnp/dlane properies name to
> MediaServerSpec2 names.
> 1 - Should we manage only properties defined in MediaServerSpec2 and
> drop other properties send by the server?
> -> I think we should manage all properties
I disagree. In general I think we should only manage properties that we
actually support. I don't think we want to fill our code full of
properties that we don't currently and may never use. It will make the
code base bigger and more difficult to maintain.
I'm not sure to get the whole image for this feature.
We are a middle-ware, we don't really use these information, it's for
external DMP/DMS.
We just check/parse properties. We get lists from DMS for DMP. I don't
think if our role to filter these lists.
If we limit the list of properties, we are going to limit the functionality
of DMP (not able to sort, search, ... on some properties).
A client building its own DMS/DMP will be limited to our list of properties?
I think it's not our responsibility to limit the functionalities of a DMP.
MSU is a helper. We should not alter data.
We could make data more usable/readable/... but not alter them.
While answering question 5, I just remember that in the API proposal, CAPs
are string array (with properties name), not int array.
So as for 5, using string array, we don't limit the DMP capabilities.
For checking/filtering, instead of using bit field (faster I agree), we
should just use hash table.
What could be weird it's to be able to sort/search on properties that could
not be browsed/displayed.
[snip]
>
> 5 - How to manage Vendor-defined values (for Feature list, or for
> property's value)
> a - We could define a single const "VENDOR-DEFINED" mask for all
> features/property's values
> b - Define a mask by feature/property value (like
> FEATURE-VENDORE-DEFINED, UPNP-CLASS-VENDOR-DEFINED) etc... The same
> assigned to all vendor defined property values
> c - Define a unique value for each vendor-specific property value.
> UPNP-CLASS-VENDOR-DEFINED-X
>
> If solution 'a' is enough, I'll go with it.
Do we need to manage these values at all? Can we not just pass the values
we get
from UPnP directly to our clients? This is what happens to most property
values
at the moment, with some notable exceptions, e.g., Type, that we map for
MediaServer2Spec
compatibility. What particular use case did you have in mind?
It's already the case. In the API proposal email, feature list is an array
of strings.
It's for internal use only. It's faster to manage/check using int rather
string in code.
But DMP get an array of string.
--
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
9:45 p.m.
Hi Ludovic,
On Thu, 2012-08-16 at 12:23 +0200, Ferrandis, Ludovic wrote:
On Thu, Aug 16, 2012 at 11:01 AM, Mark D Ryan
<mark.d.ryan(a)linux.intel.com> wrote:
Hi Ludovic,
On Tue, 2012-08-14 at 12:16 +0200, Ferrandis, Ludovic wrote:
> Hi,
>
> I'm looking to add new functions or new properties in
> com.intel.UPnP.MediaDevice interface to manage the features
below:
>
>
> GetSearchCapabilities()
> GetSortCapabilities()
> GetSortExtensionCapabilities()
> GetFeatureList()
>
> DLNA_CAPS
>
> In props.h we don't list all existing properties defined in
> ContentDirectory service:2, Appendix B, page 114 gor upnp:
(base
> properties) and res: (resource properties).
> There is a Class Properties Overview (Table C-1: page 148)
that
> defined 132 properties.
> We also need to translate upnp/dlane properies name to
> MediaServerSpec2 names.
> 1 - Should we manage only properties defined in
MediaServerSpec2 and
> drop other properties send by the server?
> -> I think we should manage all properties
I disagree. In general I think we should only manage
properties that we
actually support. I don't think we want to fill our code full
of
properties that we don't currently and may never use. It will
make the
code base bigger and more difficult to maintain.
I'm not sure to get the whole image for this feature.
We are a middle-ware, we don't really use these information, it's for
external DMP/DMS.
We just check/parse properties. We get lists from DMS for DMP. I don't
think if our role to filter these lists.
If we limit the list of properties, we are going to limit the
functionality of DMP (not able to sort, search, ... on some
properties).
A client building its own DMS/DMP will be limited to our list of
properties?
I think it's not our responsibility to limit the functionalities of a
DMP. MSU is a helper. We should not alter data.
We could make data more usable/readable/... but not alter them.
Can you provide some examples of properties that you would like to
expose that are not already exposed?
I think we already support more properties than most DMSs expose. Also,
we are limited to supporting the properties that are supported by
gupnp-av. We cannot for example support upnp:price as this is not
supported by gupnp-av. I think we already support most if not all of
the gupnp-av properties, so there isn't very much we can add, without
extending gupnp-av itself.
My main concern here is to avoid wasting a lot of time adding support
for properties that we do not currently need, cannot technically support
without modifying our dependencies, and which no one wants to use. I
would prefer to add support for any missing properties on a case by case
basis as and when they are required.
While answering question 5, I just remember that in the API proposal,
CAPs are string array (with properties name), not int array.
So as for 5, using string array, we don't limit the DMP capabilities.
For checking/filtering, instead of using bit field (faster I agree),
we should just use hash table.
I disagree. Using a hash table is considerably slower than using a bit
field and it uses more memory. A hash table is overkill here and
replacing the bitfield with a hash table would require lots of
modifications. Why spend a lot of effort changing code that works fine
for something that is slower and less memory efficient? I concede that
if we ever end up with more than 64 properties we will have to change
the code (not necessarily to use a hash table though), but let's cross
that bridge when we come to it.
What could be weird it's to be able to sort/search on properties that
could not be browsed/displayed.
[snip]
>
> 5 - How to manage Vendor-defined values (for Feature list,
or for
> property's value)
> a - We could define a single const "VENDOR-DEFINED" mask for
all
> features/property's values
> b - Define a mask by feature/property value (like
> FEATURE-VENDORE-DEFINED, UPNP-CLASS-VENDOR-DEFINED) etc...
The same
> assigned to all vendor defined property values
> c - Define a unique value for each vendor-specific property
value.
> UPNP-CLASS-VENDOR-DEFINED-X
>
> If solution 'a' is enough, I'll go with it.
Do we need to manage these values at all? Can we not just
pass the values we get
from UPnP directly to our clients? This is what happens to
most property values
at the moment, with some notable exceptions, e.g., Type, that
we map for MediaServer2Spec
compatibility. What particular use case did you have in mind?
It's already the case. In the API proposal email, feature list is an
array of strings.
It's for internal use only. It's faster to manage/check using int
rather string in code.
But DMP get an array of string.
--
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
11 p.m.
On Thu, Aug 16, 2012 at 1:45 PM, Mark D Ryan <mark.d.ryan(a)linux.intel.com>wrote:
Hi Ludovic,
On Thu, 2012-08-16 at 12:23 +0200, Ferrandis, Ludovic wrote:
>
>
> On Thu, Aug 16, 2012 at 11:01 AM, Mark D Ryan
> <mark.d.ryan(a)linux.intel.com> wrote:
> Hi Ludovic,
>
> On Tue, 2012-08-14 at 12:16 +0200, Ferrandis, Ludovic wrote:
> > Hi,
> >
> > I'm looking to add new functions or new properties in
> > com.intel.UPnP.MediaDevice interface to manage the features
> below:
> >
> >
> > GetSearchCapabilities()
> > GetSortCapabilities()
> > GetSortExtensionCapabilities()
> > GetFeatureList()
> >
> > DLNA_CAPS
> >
> > In props.h we don't list all existing properties defined in
> > ContentDirectory service:2, Appendix B, page 114 gor upnp:
> (base
> > properties) and res: (resource properties).
> > There is a Class Properties Overview (Table C-1: page 148)
> that
> > defined 132 properties.
> > We also need to translate upnp/dlane properies name to
> > MediaServerSpec2 names.
>
> > 1 - Should we manage only properties defined in
> MediaServerSpec2 and
> > drop other properties send by the server?
> > -> I think we should manage all properties
>
>
>
> I disagree. In general I think we should only manage
> properties that we
> actually support. I don't think we want to fill our code full
> of
> properties that we don't currently and may never use. It will
> make the
> code base bigger and more difficult to maintain.
>
>
>
> I'm not sure to get the whole image for this feature.
>
> We are a middle-ware, we don't really use these information, it's for
> external DMP/DMS.
> We just check/parse properties. We get lists from DMS for DMP. I don't
> think if our role to filter these lists.
> If we limit the list of properties, we are going to limit the
> functionality of DMP (not able to sort, search, ... on some
> properties).
> A client building its own DMS/DMP will be limited to our list of
> properties?
>
> I think it's not our responsibility to limit the functionalities of a
> DMP. MSU is a helper. We should not alter data.
> We could make data more usable/readable/... but not alter them.
Can you provide some examples of properties that you would like to
expose that are not already exposed?
I think we already support more properties than most DMSs expose. Also,
we are limited to supporting the properties that are supported by
gupnp-av. We cannot for example support upnp:price as this is not
supported by gupnp-av. I think we already support most if not all of
the gupnp-av properties, so there isn't very much we can add, without
extending gupnp-av itself.
My main concern here is to avoid wasting a lot of time adding support
for properties that we do not currently need, cannot technically support
without modifying our dependencies, and which no one wants to use. I
would prefer to add support for any missing properties on a case by case
basis as and when they are required.
Ok. I didn't go this deep into the code.
I have start to look at gupnp-av
Ok. I will start another thread. I'm currently doing a study about what
support gupnp-av or not.
Basically, only V1 spec for instance. No V2 spec.
I will list what's missing and if we need missing properties.
>
> While answering question 5, I just remember that in the API proposal,
> CAPs are string array (with properties name), not int array.
> So as for 5, using string array, we don't limit the DMP capabilities.
> For checking/filtering, instead of using bit field (faster I agree),
> we should just use hash table.
I disagree. Using a hash table is considerably slower than using a bit
field and it uses more memory. A hash table is overkill here and
replacing the bitfield with a hash table would require lots of
modifications. Why spend a lot of effort changing code that works fine
for something that is slower and less memory efficient? I concede that
if we ever end up with more than 64 properties we will have to change
the code (not necessarily to use a hash table though), but let's cross
that bridge when we come to it.
>
It could be an array of boolean, index of array is id of property. Faster,
smaller.
--
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
3685
days inactive
3687
days old
4 comments
2 participants
participants (2)
-
Ferrandis, Ludovic -
Mark D Ryan