RE: [discovery-api][ISSUE-130][ACTION-654] wildcard api

> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
> 
> Le 28/10/13 22:18 , Cathy.Chan@nokia.com a écrit :
> > Thanks Jean-Claude for the proposal. I like the general idea. Please find
> some comments inline.
> > - Cathy.
> >
> >> -----Original Message-----
> >> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
> >> paristech.fr]
> >> Sent: Thursday, October 24, 2013 11:49 AM
> >> To: Device APIs Working Group
> >> Subject: [discovery-api][ISSUE-130][ACTION-654] wildcard api
> >>
> >> Dear all,
> >>
> >> Here is proposed text for ISSUE-130, as part of ACTION-654:
> >> Propose text for network service discovery to define wildcard api and
> >> feature detection
> >>
> >> This is modelled against the latest text for getNetworkServices.
> >> I am very flexible for the name of that function, as well as other
> >> aspects of the proposal.
> >>
> >
> > I would suggest naming the function such that it is immediately
> > obvious that it is a
>  > close relative of getNetworkServices. discover() is so different that people
> would begin  > wondering if these are two completely different and
> unrelated things, which they are not.
>  > How about something like getAnyNetworkServices?
> 
> I am good with getAnyNetworkServices.
> 
> >
> >> ====================
> >>
> >> promise = window.navigator.discover(fragment)
> >>
> >> Immediately returns a new Promise object and then the user is
> >> prompted to select discovered network services that have advertised
> >> support for a service whose type contains the given fragment.
> >> If the user accepts, the promise object is resolved, with a
> >> NetworkServices object as its argument.
> >> If the user declines, or an error occurs, the promise object is rejected.
> >>
> >> The implementation of the discover function is optional, as it
> >> requires the user agent to monitor the network for device and service
> >> announcements. A web application may test the existence of the
> >> discover function by testing whether window.navigator.discover is a
> function.
> >>
> >> When the discover(fragment) method is called, the user agent must run
> >> the following steps:
> >>
> >> 1. Let Network Service Promise be a new Promise object.
> >> 2. Let Network Service Promise's Resolver be the default resolver of
> >> Network Service Promise.
> >> 3. Return Network Service Promise, and run the remaining steps
> >> asynchronously.
> >> 4. Process: Let services found be an empty array.
> >> 5. For each available service in the list of available service
> >> records run the following steps:
> >> 5.1 If available service's type attribute contains the fragment
> >> argument then
> >
> > We need to be more specific about what "type attribute contains the
> fragment argument" means. I would say "If the fragment argument is a
> substring of available service's type attribute ...".
> 
> I like your proposed text.
> 
> >
> >> let matched service equal the value of available service.
> >> Otherwise, abort the remaining sub-steps and continue above at the
> >> next available service.
> >> 5.2 same as 9.2 of getNetworkServices
> >> 6+. same as 10+. of getNetworkServices
> >>
> >> ====================
> >>
> >
> > Your proposal does not include changes to the rule for adding an
> > available service (Section 8), which is run when a new network service
> becomes available on the network and the UA updates the servicesAvailable
> attribute of and dispatches servicefound events to the affected
> NetworkServices objects.
>  > Is that intentional? If so, why?
> 
> The implementation of discover/getAnyNetworkServices is entirely based on
> the "list of available service records" that the implementation maintains. The
> current section 8 already deals correctly with that part, and I felt that no
> change was necessary. I actually spent a long time reading and rereading the
> beginning of that section to be sure I understood all the implications of each
> sentence (from the previous draft).
> Do you think there is something I missed and a change in that section is
> necessary to implement discover/getAnyNetworkServices ?
> 

[[
3.For each requested control type of the requested control types in service manager run the following steps: 
	1.If network service record's type property does not equal requested control type then abort any remaining sub-steps and continue at the next available requested control type. 
	2.Set the 'service type in current service manager' flag to true, abort any remaining sub-steps and continue.
]]
A service manager that was created in response to a discover/getAnyNetworkServices call does not have "requested control types", but "requested fragment". The condition in 3.1 would become "If the requested fragment is a substring of the network service record's type property" if the service manager was created in response to a discover/getAnyNetworkServices call. These steps therefore need to be adapted to accommodate both types of service managers.
 
> >
> > Also, since the goal of the function is to support "wildcard search", are we
> aiming at supporting the ultimate wildcard "*"?
> 
> In my implementation, matching "*" is possible (with a "" fragment).
> I do not see a (technical/implementation) reason to exclude it from the API.

No reason to exclude but it's not clear from your proposed text. It needs to be stated in the definition of the function / fragment argument that an empty string means getting all network services regardless of type.

- Cathy.

Received on Tuesday, 29 October 2013 15:16:36 UTC