search

reTHINK-project / dev-discovery

Apache License 2.0
0 stars 0 forks source link

Integration with Runtime #1

Open pchainho opened 8 years ago

pchainho commented 8 years ago

This issue is created to discuss the integration of the discovery server in the runtime to enable global discovery.

The proposal is to use a similar approach as done with Domain Registry ie:

ingofriese commented 8 years ago

I think I agree, but to me the domain registry discovery is not that clear so 1) query the discovery service about the GUID for a certain user 2) query the global registry about the domain registry associated to each GUID

then the Hyperty contacts the domain registry for a certain Identity and then connects to the endpoint right?(correct me if I'm wrong) Where do I get the Identity? Is the GUID not enough to get connected?

pchainho commented 8 years ago

In the scenarios we have, we are using IDP Identifiers that people would know outside of reTHINK like emails. This would also facilitate the bootstrap of reTHINK eg by inviting all your email contacts to your reTHINK enabled contact list and at the end to the reTHINK ecosystem.

I guess this would only be needed once and then the GUID would be used next time.

At this point the domain registry discovery uses user IDP identifiers but I guess it can also support GUID, @rjflp ?

Another future discussion would be to also support Global Discovery of Hyperty Objects eg Chat Rooms.

ingofriese commented 8 years ago

Correct me if I'm wrong .. I means for example....I want to get connected to paolo@pt.com (your id) at example_rethink_domain. In order to get it right. 1) I install a rethink client on my pc 2) then I discover "Paolo" "PT" "rethink expert"....find one entry with 1) GUID and 2) your IdP-Identity

3) GUID is resolved immedatly to domain-registry URLs 4) now I have to tell my client he should connect to the domain registry and find all hyperties of the identity "Paolo"

My question is how do I get from step 3 to 4?

pchainho commented 8 years ago

In case "example_rethink_domain" is not your domain it would trigger the protofly mechanism to load and instantiate "example_rethink_domain" stub and then you use it to query "example_rethink_domain" domain registry. All this long long process would be performed behind the scenes, the user would only click eg chat with "paolo@pt.com" .

One question: are you also using some kind of P2P storage network like the global registry, and then each domain could have each one a discovery service instance ?

ingofriese commented 8 years ago

But infact the discovery server has to deliver both 1) the readable ID "paolo@pt.com" 2.) the rethinkID right?

The dicovery service is currently a single server solution with a Web-Interface were everybody can create, change and delete profiles.

But there are several theoretical ways to distribute it. 1.) the solr search enginne can be configured in a cloud modus where different cores and indexes can take part. So then we can run e.g. a solr instance in Portugal and one in Germany. A search request would go to both cores. 2) The repository for the profiles can be hosted at different locations. You can create your own CMS, where a PT user can create, change, and delete a profile in your way. You just index it at the service.

pchainho commented 8 years ago

the discovery server would only have to return the GUID (rethinkID?) since you are already providing the IDP identifier ("paolo@pt.com") in the query.

The discovery service is currently a single server solution with a Web-Interface were everybody can create, change and delete profiles. But there are several theoretical ways to distribute it.

This sounds more like a central server that can be clustered in different machines for scalability and fault tolerance purposes.

jmcrom commented 8 years ago

@pchainho I think discovery should enable users to search for contacts based on whatever clues thay may know, and not only based upon some identifier/email (just like google or shodan today)

for instance I search "paolo portugal telecom" and i get mosty a GUID that will be translated in CSP domains (thru Global Registry) and afterwards to hyperty endpoints (thru Domain Registries)

more globally discovery is a service that may be provided by several actors, just like CSP are many

pchainho commented 8 years ago

yes, I understand that, but then queries can also be done by only using an IDP Identifier, right?

more globally discovery is a service that may be provided by several actors, just like CSP are many.

But CSPs are not domain agnostic. When I create my profile it should be discoverable from any domain ie the global discovery query should be performed to some address that is domain agnostic as we do for the global registry. For example, we use global://registry as the address for the global registry and for the global discovery we could use global://discovery.

rjflp commented 8 years ago

@pchainho I seem to have a very different understanding of what the Discovery Service is. I always heard that the Discovery Service is no "a single service" but a service that can be provided by different SPs. It is a search engine, and like search engines, there is no single one, to be used like you describe, via a library. In order to foster innovation and competition, there can not be a single search engine. Users must be free to select which one to use.

So far I've assumed that the search engine is a site, to be used by humans, and not by the runtime. @ingofriese Users have to register with a particular (or several) Discovery Services, right? There isn't supposed to be a single, "universal", Discovery Service.

I think that what @pchainho requires is probably best served by the proposals discussed in issue https://github.com/reTHINK-project/dev-registry-global/issues/11

Another, simpler solution, would be to consider that step 2 is to be made "manually" by the user and not by the runtime.

1) I install a rethink client on my pc 2) then I discover "Paolo" "PT" "rethink expert"....find one entry with 1) GUID 3) GUID is resolved immedatly to domain-registry URLs, using Global Registry 4) now I have to tell my client he should connect to the domain registry and find all hyperties of the identity "Paolo".

ingofriese commented 8 years ago

1) regarding service vs. single instance: I agree with Ricardo. It depends what you expect. We can e.g .distribute the profile database and management and have a common search index. Even the index may have variuos shards hosted at different players. So we can discuss what make sence for the next phase.

2) For the current implementation I need to know: I want to search on my "discovery service"- click at an result and get conected via a rethink client. Similar to I click at "mailto" and a mail client opens up or I tip at a phone number and my phone starts to dial.

Is it possible to start a rethink client via a url with parameter?

ingofriese commented 8 years ago

Regarding the distributed service I would suggest: 1) to have a single instance for each partner or (later any partner who is intersted) 2) to enable instances to forward the search request also to other intances in a p2p manner.

For my implementation I need to know: Is it possible to start a rethink client via a url with parameter?

sbecot commented 7 years ago

to have a msg node connector to the Discovery server.

I don't think this method is efficient. As discussed in Lisbon, why are you routing messages in the server node when they can be done directly by the client. This seems to be unefficient. Also, a rest interface is very simple to implement (more than a proprietary method). Another thing to consider: if the interface of the platforme changes, you will need to change the connector, which means upgrading a messaging node. If this is done by the client, you will need to upgrade the client code with a new version in the catalogue.