From DAP WG Wiki
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|
|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”|
||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 .||No.||No.|
|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|