-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to know URLs of the different servers? #430
Comments
Discussed on call how we covered in VISSv1, a well known URI |
Ok, this is really important I would think that we need to invoke the VISS server somehow...either by providing a proxy api or by handing back a configuration. Putting on the hat of a client implementor they really only want to worry about this once across OEMS. |
I think the port numbers used by the different servers should be standardised.
|
So, I don't understand why we open up for fragmentations over retrieving the whereabouts of the AGTS and ATS servers if we don't have to. Could we simply not add a standard way of asking the server ? |
Concering ports - I have no problem in that the specficiation states a recommended/default port, but I assume that stating that port XXXX is mandatory to use could cause problems, that deployments by different reasons may want to select a different port. I.e. implementations are encouraged to use the default path/port, but should preferably have mechanisms to use a different path/port. In #385 we discussed the possibility to ask the server for capabilities. Would it be possible to use the same or similar mechanism for asking for AGTS/ATS. Possibly even as a generic key-value method where you can ask (without authorization on VISS level) the VISS server and get back a list of key-value-pairs, possibly including both agts/ats info as well as information on proprietary extensions to VISS. Possibly something like below
This is based on the assumption that none of the information provided is confidential. But it would be possible to think of a solution where only a subset is returned if not token is provided. I.e. first you need to do a call to get agts/ats, then when you have the token you can call again and get the complete list. |
@peterMelco, |
@erikbosch, |
Well if a client can handle VISS-server address as configuration, I believe they can handle port as configuration as well. And do we want to limit ourselves to that e.g. AGTS/ATS must be on the same address (e.g. |
The VISS server is typically deployed in-vehicle, addressed by an IP address, and the AGTS off-vehicle, addressed by a domain name. The solution might be to have an optional "recommendation" of ports and IP/domain address patterns, and then say that it can be overridden by "configuration" data, where the provisioning details are out of scope. |
Fixed in PR433 |
From Issue 425:
This is a relevant question which I think needs to be discussed in the WG before being answered.
I think it has to be analysed separately for the scenarios:
Web application and AGTS deployed off-vehicle, ATS and VISSv2 server deployed on-vehicle.
All four deployed on-vehicle.
The text was updated successfully, but these errors were encountered: