Integration of Discovery Service and Apps

[rjflp]

On July 15th, there was a discussion on the WP4 telco on how to integrate the Discovery Service and Apps.

The goal of the Discovery Service is to perform searches to discover a user's GUID. With that GUID we can establish a call using the registries (Global and Domain). However, a GUID can lead to several SPs and even more hyperty instances. How do we go from a GUID in the Discovery Service to a call?

The simpler and sure to work alternative would be to use the Discovery Service to obtain a GUID and them provide that GUID to an App, that would know which hyperty to use. This could be something as simple as copy-and-past. The user would choose the app he wants to use. An improvement would be for the Discovery Service (a webapp) to also provide a REST API, so that applications would allow discovery to be performed within the app itself.

The more sofisticated approach would be for one to click on the search result on the Discovery Service webpage and have the call be completed from there. This would likely entail the following steps: 1) User clicks on a GUID, runtime takes over 2) Runtime uses Global and Domain registries to determine available types of hyperties (resources) 3) Runtime prompts user for the type of communication to use (voice, video, etc) from those available 4) The Runtime launches the user's preferred app for that resource type, in order to complete the call.

The first alternative is obviously the simplest one. The second would probably require more development effort.

We must decide with path to take, or both, weighing in on the available resources, project goals and the effort required to pursue each avenue.

[sgoendoer]

Well, as already discussed on Friday, I think the first option (the simpler) one is the main use case for us.

1.) User opens app X 2.) uses the search function of the app to search for user Y 3.) In the background, the app queries the discovery and gets a list of results 4.) The app now resolves the GUIDs via both registries and gets a list of results (users and running/compatible hyperties) 5.) The results are displayed to the user, who just clicks on the desired endpoint to connect to (with app X)

Anyhow, for demonstration and testing/dev purposes, a web frontend would be beneficial to have. Also, this could be used to let users search "manually" like with Google. If these results are then (optionally?) used for direct initiation of a connection is another question.

IMO, both the integration into the app and the web-frontend would require some kind of well-designed REST-API. So the design of this API should be built in a way so that it serves both purposes. Maybe we could start with having a simple demonstrator as a web page, then doing the integration into the apps, and if there's enough time and resources left in the end, work on the automated instantiation of the hyperty/app via a web interface.

[ingofriese]

I see two general ways to apporach this issue. 1) The "web way":

1. user searches some other user in discovery service
2. user clicks on the GUID on a web-page
3. now he sees a website with available options
   • you can connect using video, chat etc.
     1. the he clicks on his choice e.g. chat
     2. and now the Runtime starts

This keeps all the selection logic in the web. The Runtime or more precisly the app don't have to integrate any UI or user interaction for selection or discovery. It is started in parameterized way. @rjflp this means we need a REST interface to the domain registry

The second option is the "App Way" 1) The user starts the application 2) The user looks up a user from within the application via discovery REST-interface 4) Runtime uses Global and Domain registries to determine available types of hyperties (resources) 5) Runtime prompts user for the type of communication to use (voice, video, etc) from those available 6) The Runtime launches the user's preferred app for that resource type, in order to complete the call. (Ricardo I just copied your steps :-)

In this way all the UI and user interaction has to be implemented by the app.

[pchainho]

The user experience should be designed by the App Service Provider as much as possible e.g. for standalone Apps in smartphones it is not very user friendly to force the user to go outside the context of the app to perform a user search. Also we should promote use cases like "automated contacts import" or "automated invitation from existing contacts eg emails" to promote the adoption of reTHINK by new users.

[jmcrom]

@ingofriese from what i understood last friday you have developed the "web way" (almost). So to get the "app way" what you have to do is defining a proper REST api between the search web page and the search engine

@pchainho okay for importing feature but let's begin by designing our applicatons in nominal way
moreover these exisiting contact lists are domain-bound (so referenced by userIDs) so discovery api may be a way to get corresponding GUIDs and thus feed address book/graph connector

[ingofriese]

@pchainho I think we should go both ways. I we only allow to search people from within the App we loose flexibilty. It would be for example not a good idea when we only allow to look for phone numbers from a phone. No we using google, other web-sites, business cards, and most important other applications. Thats important to ebanble a whole eco-system. Right? never the less Paolo you are right there should be also the possibility to design every user interaction within the app. So for the "App-way" we are going to provide a rest interface where an application can send a search stirng and gets back a JSON list of results. For the "web-way" we need 1) a REST interface for domain registry ( @rjflp is it possible? I mean an interface that is also availbale without runtime) 2) we need runtimes that can be startet with the callee address as parameter start hyperty/application xyz and connect to destination http//rethink.orange.fr#user123 ( @pchainho is this possibel?)

[jmcrom]

@ingofriese about your last comment i would rather say "we need a way to start runtime or application while indicating callee endpoint address to be connected"

[ingofriese]

@jmcrom exactly...

[pchainho]

A discovery API and associated Lib in the runtime as proposed here would support all these use cases. It is not clear to me the difference between the "web way" and the "app way" but I guess it is just a question of architecture ie having the discovery service separated from the app with an API or not.

"we need a way to start runtime or application while indicating callee endpoint address to be connected"

If I understood you correctly, this is a business capability to be provided by an App and/or Hyperty executed in the runtime. Example: currently the Connector Hyperty can be instantiated by calling its catalogue link (requireHyperty(<catalogue link>)) and then call connect(<callee hyperty address>) . On top of this you can build an App that works as you just mention but this is just one possibility among many others.

[rjflp]

Regardless of what we end up achieving by the end of the project, we need to prioritize. As such, I would propose to:

Start with the basic search engine and copy and past the GUID to the App. This is obviously the worst user interface, by keeps discovery website and Apps development and testing separate.

Proceed with @ingofriese "App Way" (with a few modifications of my own) 1) The user starts the application 2) The user looks up a user from within the application via discovery REST-interface 4) The app uses the Runtime to consult the Global and Domain registries to determine available types of hyperties (resources) 5) App prompts user for the type of communication to use (voice, video, etc) from those available and supported/preferred by the app. 6) The app completes the call.

Latter, if resources and time allow, we could proceed to the "Web way".

What do you think?

[rjflp]

@ingofriese

For the "web-way" we need 1) a REST interface for domain registry ( @rjflp is it possible? I mean an interface that is also availbale without runtime)

The Domain Registry is accessed through a REST interface. However, currently, the security model assumes that all accesses come from the SP's message node.