Re: [dLeyna] MediaServer2 spec

[Mark D Ryan <mark d ryan linux intel com>]

On Thu, 2012-06-21 at 12:55 +0200, Jens Georg wrote:
> On Mi, 2012-06-20 at 14:49 +0200, Mark D Ryan wrote:
> > Hi,
> > 
> > On Wed, 2012-06-20 at 12:20 +0200, Jens Georg wrote:
> > > Hi,
> > > 
> > > from https://01.org/dleyna/documentation/item-objects I see that you 
> > > found an issue with the org.gnome.UPnP.MediaItem2 interface. 
> > > 
> > > How are the semantics of the Resources property? Should you duplicate
> > > the URLs in the item's URLs property, or does Resources only have the
> > > additional meta-data and no URLs?
> > > 
> > The way things currently work is that the item's URL property only ever
> > contains a single URL.  By default this is the first URL returned by the
> > DMS, but it is configurable, by a call to
> > com.intel.MediaServiceUPnP.Manager.SetProtocolInfo.  The other item
> > properties that are transcoding dependent, e.g., the MIMEType, all have
> > the correct values for this URL.
> 
> Ok, so you'd suggest to keep the "preferred" item in the global
> meta-data + url (e.g. by default the non-transcoded original resource)?
> 

Yes.  This way we can maintain backward compatibility.  Also, if the
client is only interested in the preferred resource he can filter out
the Resources property in a call to Search or ListChildren.

In our implementation the properties of the preferred resource are
currently duplicated in the Resources array, but we could remove them.
I guess the only downside of doing so is that it would make it slightly
more difficult for clients who genuinely want to retrieve the properties
for all resources.  The upside is that there would be no data
duplication.


> Btw, the support for several URLs was never meant for different
> resources but different transport layers like HTTP and RTSP
> 
> > 
> > Each element in the resource array contains separate copies of all the
> > item's properties that can change with transcoding, including the URL.
> > Here's an example,
> 
> That makes sense.
> 
> [example]
> 
> > 
> > > Just wanted to say that this spec is not set in stone, and especially
> > > adding optional properties "upstream" isn't a problem.
> > > 
> > > For more deeper issues that can't be solved in a backwards-compatible
> > > way, we can always discuss about version 3 :)
> > > 
> > 
> > Great.  That's good to hear.  I guess the best place to discuss this
> > would be on the Rygel mailing list, right?
> 
> Yes, I'd say so. CCing there.
> 
> I also noticed the *Ex() functions in
> https://01.org/dleyna/documentation/server-objects. This is also
> interesting in Rygel for future versions in conjunction with the fixing
> of the whole "sorting in plugins" bugs (see
> https://live.gnome.org/Rygel/Roadmap/OSixteen, "Sorting in plugins"
> section)
> 
> 

Right, so the two main things we added to the existing MediaServer2Spec
interfaces were the Resources array and the Ex functions.  As you point
out, the Ex functions allow clients to specify a sort order.  We also
added an extra return value to SearchEx that indicates the total number
of items matching a search query.  This is useful if you use the Offset
and Max parameters to limit the number of items returned.


Mark