additional entry of user domain

[ingofriese]

I'd like to see an additional JSON tag "domain" or "service-domain". In the current datamodel everything is written in "userIDs": I can work with it somehow and extract the userID and domain from the URL.; but I think since we use JSON anyway we should clearly name it "domain":"tlabscloud.com" "userID": "user://gmail.com/ingo.friese" or "ingo.friese@gmail.com" I think this is not a big issue but makes things much cleaner to implement.

[fbeierle]

As discussed in this Issue: https://github.com/reTHINK-project/dev-registry-global/issues/12#issuecomment-232905961 we already have a defined format for the UserIDs. There are some drawbacks to adding additional fields to the Global Registry Record (GRR):

We would just add redundant information. The GRR would be bigger and would have to be checked for inconsistencies, both of which would create a higher load on the Global Registry.

Extracting the desired information from the UserID should be much more simple than changing the GRR-related implementations and tests in both Global Registry and Runtime Core.

[jmcrom]

we may not change the storage format but provide additional REST interface if needed

[ingofriese]

@fbeierle I think we have now a much clearer picture than month ago about the discovery process. The discovery service needs from the GRR two things to contact the Domain-Registry

1.) the url of the domain-registry and (e.g tlabscloud.com) 2.) the id of the user (idp-URL/user-name) (e.g. in.friese@gmail.com)

The current format puts both 1) und 2) in one URL and calls it "userID" what is basically wrong because there is much more information in it like domain etc. I would agree to keep it this way if I could use the URL directly and contact the domain-registry. But I can't. I have to map the tlabscloud.com to a certain IP-address of the domain-registry interface. Because there is a difference btw. well-known URL and the actual domain-registry-API address. So we have to splitt the userID-URL anyway in two parts anyway.

I think the JSON Formate should be used to clearly state [key,value] pairs. So lets use it.

The extra load for the "domain" tag I save in userID-URL because here I need just to write the userID like the tag states it.

So don't get me wrong. This is not a big issue. I can deal with it. The only thing is that the naming is missleading and the interface simply not clean if we keep it this way.

[rjflp]

Would a library to do this "splitting" work? No need for everyone to have to write this code over and over.

[ingofriese]

@rjflp Yes the splitting work could be done in a library. But to be honest: The interface delivers a lot of tags: active, salt, timeout etc. with all the security and JWT dance: But the really two important once.....we put in one String where you need an additional library?...and than with a wrong tag or missleading tag name? common.... Currently we have the chance to correct it very easy. Later there might be more applications and than they all have to change it

[fbeierle]

We could either have redundant fields, which we have strong arguments against. Or we change the format of the UserIDs to have several fields instead. I'm unsure, what implications this would have. @pchainho Do you have an opinion on this?

[pchainho]

If I understood it correctly, I would be in favor of having the service domains in the Global Registry (I think I've already proposed something similar somewhere else)

On the other hand changing the format of User URLs have a big impact

[ingofriese]

@pchainho I think we should not change the format of the user URL "user://gmail.com/in.friese" We just should devide the URL like "tlabscloud.com/user/user://gmail.com/in.friese" In two parts (domain and identity). The complete URL nowbody uses sofar but the discovery service. So there should not be any impact.

[jmcrom]

so if i summarize: the api may return

• either 1 field containing complete user URL
• or 2 fields containing the domain and the userid within this domain

it seems to me that the better choice is what the client services of this api would prefer

[sgoendoer]

Generally, the "client services" in question here would be mostly the Graph Connector and the Discovery, right? So what would be most beneficial for these two components? One URL or a JSONObject with separated parameters?

[pchainho]

I would say the global registry can be used by any component including Hyperties and should return a json object with addresses compliant with our address model ie the User URL and a second attribute with the user's domain.

[rjflp]

@sgoendoer The main "client service" is the runtime.

[rjflp]

Any solution works for us. We just need to know what to implement. Where else are these URL used? We should use the same data format (json objects) everywhere.

[ingofriese]

@jmcrom exactly you name the poblem @pchainho I totaly agree with you @rjflp from the doamin registry perspective there should be nothing to be changed @sgoendoer you know my preference :-) - > two JSON arguments

[sgoendoer]

@jmcrom Having a way to request either format as JM proposed will only work with an ugly workaround storing BOTH formats in the dataset. This is because the GReg CAN NOT change the dataset when storing or returning it. Otherwise, the integrity would be voided.

How and when are we making a decision to change the current format for the dataset?