ServiceDiscoveryComparison

The table below compares the service discovery concepts from Webinos, Opera/CableLabs and Google (Web Intents and Web Introducer).

Feature	Webinos proposal	Opera/CableLabs proposal	Google Web Intents	Google Web Introducer
Level of abstraction	Javascript API to obtain Javascript-based Service APIs	Javascript API to obtain HTTP Service URL endpoints	Javascript API to allow client web application to find and communicate with service web application	Javascript API to allow client web application to find and communicate with service web application
Relation to underlying low level discovery/communication mechanisms	Agnostic to underlying low levels discovery/communication mechanisms. This is subject for implementation of discovery infrastructure and services based on supported low level discovery and communication mechanisms	Agnostic to underlying low levels discovery/communication mechanisms (but includes standard processing rules for Zeroconf and UPnP).	None	None
Location of services	In device, locally connected, local network and web-based services	In device, locally connected, local network and web-based services	Anywhere, service is represented by a web application that hides any underlying low level service access methods	Anywhere, service is represented by a web application that hides any underlying low level service access methods
Network infrastructure required	Underlying infrastructure for registering user’s devices/services (more details)	Both an underlying Zeroconf and UPnP infrastructure	None (Claes: Rich, I believe a “Web Intents server”is needed. Please explain your view	“Web Introducer server”
Identification of service type	URI identifying a JavaScript API to access the service	Service type tokens exposed from the underlying discovery mechanisms	A service (intent) is defined by: Action: a URI defining what to do (share, pick, view, etc) Type: the data type to perform the action on (image, url, json etc)	A service (intent) is a string identifying an interaction pattern between a Client and a Service. Examples are bookmark for sharing, link to media file, user's stream of incoming SMSs
Security / access control	Based on user selection of discovered service and security mechanisms implemented for respective services. A distributed approach where policy decisions are hosted in a Personal Zone.	Based on user selection of discovered service and security mechanisms implemented for respective services. Assumes that access control is handled in the UA.	Based on user selection of discovered service and security mechanisms implemented for respective services	Based on user selection of discovered service and security mechanisms implemented for respective services
Service registration	An application can register new services through a statement in the manifest file	UA silently (i.e. in the background) handles discovery and registration of services from the local device, local network. UA also silently handles service discovery and registration on visited web sites.	To make a service (intent) discoverable it need to be registered in the UA through a simple API. The services Action, Type and URL to a web page that implements the service is registered. For example, in-page meta header registration syntax is collected as the user browses their web sites.	To make a service (intent) discoverable it need to be registered in the UA through a simple API. The service's name, supported intent strings, icons, URLs to service pages are registered.
Discovery process	UA searches for networked services at API invocation.A successCallback is issued for each service found. Timer for how long search process lasts could be set. Pending search process can be canceled	UA searches for networked services (the timing of which is at the discretion of the UA) in the local network and on user visited web sites and maintains a list of currently available services.	A web application wanting to use a service calls a simple API stating the requested Action and Type. An iframe allows the user to select one of the registered services for this Action and Type.	A web application wanting to use a service calls a simple API stating the requested intent. An iframe or a new window allows the user to select one of the registered services for this intent.
Search filter	Yes. Allows web application to search for services belonging to certain user(s), to state remote or local only services and to state location of service. Also allows the page to set a timer for how long search process lasts could be set. Pending search processes can be canceled.	No [1].	No.	No.
Communication with service	A standardized / “well-known” JavaScript API is provided to the web application to access the service.	A URL, extracted directly from the underlying service discovery process, is provided to the web application to access the service. The web page can then use standard XmlHttpRequest, Web Sockets, Server-Sent Events and Web Messaging, etc (all with implicit cross-origin resource sharing) to communcate with the service. Protocol depends on messaging format implemented in device implementing service (e.g. json, protobufs, text-based, xml, etc).	Data is sent bi-directionally between client web application page and the service web page through the Web Intents API. The format/protocol of this data exchange is defined for each Action by the Web Intents specification. Underlying communication mechanism is web messaging but this level is hided to the application developer.	Data is sent bi-directionally between client web application page and the service web page through Web Messaging. The format/protocol of this data exchange must be defined for each Intent by specific API/protocol specifications for each intent type.
Service status monitoring	onLost callback when found but not yet bound service is lost. onServiceUnavaialble and onServiceAvailable callbacks for bound services.	readyState changes fire back to web page's network service objects. readystatechange events occur on a network service object when the service becomes available or unavailable. servicesAvailable attribute is used to monitor general number of services of the authorized type currently available in the user's network(s).	No service status monitoring in the Web Intents API itself but guess that this could be handled in the specific protocol for the specific Action.	No service status monitoring in the Web Introducer API itself but guess that this could be handled in the specific protocol for the specific intent type.
Service binding lifecycle	Service binding valid until unbind() is called or client page is left. Later the binding to the service can be resumed using the saved service id.	Opera to elaborate	To be completed	To be completed
....	...	...	....	....