On Mon, Oct 7, 2013 at 10:13 AM, FABLET Youenn <Youenn.Fablet@crf.canon.fr>wrote: > Searching by service type seems appropriate from a web app point of view. > **** > > As Rich said, a web app may just need ContentDirectory service access > (slideshow) while another may need access to all ContentDirectory, > ConnectionManager and AVTransport services (streaming). **** > > It makes sense to keep it that way.**** > > ** > OK, but should an app be allowed to search for UPnP "devices"? As a way to say "I only want services of a given device type"? (and don't care of similar services associated to other device types?) > ** > > Granting access at a device level seems more comprehensive from a user > point of view.**** > > It is also probably more consistent with UPnP design.**** > > But at the end of the day, this is a browser UX decision (power users may > still prefer a pick-service-by-service UX). **** > > I am not sure why the NSD API should actually define constraints here.**** > > ** > Not completely sure about this, but I don't think is critical at this point. > > ** > > Enabling partial exposure of a device has also some benefits. > but can also lead to confusing situations isn't it? where you don't know why only some services are exposed/available. > **** > > The web app can parse the UPnP device description to request user specific > actions like activate a given missing service or grant a given service. > How would this work (after the parsing part, I mean)? You mean just parse the description are ask the user to "enable" such service? (that is probably going to be an obscure message to most users, isn't it?) /gReceived on Monday, 7 October 2013 10:01:25 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC