Re: Standardized endpoint name for VISS (was: Re: Request to make the issue list for VISS)

Hi Gunnar,

I have to be careful not to overstate what I understand to be the groups
agreed intentions are based on what was discussed.

I'm not sure that I could go much further than make the following statement:

a) Because a vehicle will not typically have an IP address on the public
internet until it is assigned a dynamic one, e.g. by the MNO and because
this IP address could change e.g. as vehicle loses connectivity for a
period, and re-establishes it, our view was that the VIS Server should be
accessible from *in-vehicle clients* and we would not try to solve the
problem of providing reliable access from the public internet.

b) A vehicle network should be able to support multiple VIS Servers on that
network.

If anyone on the thread disagrees or would re-express the above, I would be
grateful if you would correct me.

Thanks and regards,

Kev


*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 12 September 2017 at 09:46, Gunnar Andersson <gandersson@genivi.org>
wrote:

>
> On Tue, 2017-09-12 at 09:23 +0100, Gavigan, Kevin wrote:
> > Hi Gunnar,
> >
> > Thanks, you raise and make some very pertinent points.
>
> OK, good.  I was hoping someone would go through each of them and just
> confirm that what I said was true, so far.  Because this is a process to
> lead to a conclusion.  But I suppose maybe you agreed now, implicitly?
>
> >
> > Suggest that another important point is:  What if an OEM wants to install
> > two or more VIS Servers on the same vehicle network.
>
> Yes even name resolution of a single well known name would not solve that.
> You'd have to either have a discovery protocol of some sort (and then
> zeroconf comes to mind -- yes I now saw the feedback Ted relayed,
> mentioning
> mDNS, which is the same thing IIRC?)
>
> Or you would leave that up to OEM-specific configuration that is somehow
> passed from system to "app" when the app is launched.
>
> I think there's a limit to how far you will be able to here specify the
> exact application standard, which includes APIs like that between OS (or
> "application manager") and app.  But a single well-known name might be
> useful still.
>
> In fact... come to think of it - is this thing perhaps better defined in a
> different specification, one which specifies an (automotive) web
> application
> standard, rather than in the server specification?
>
> >
> > For example, the designers of the instrument cluster might decide to
> > implement the VISS specification and install a VIS Server in the cluster
> > in order to get vehicle speed, engine rpm, fuel levels etc and display
> > them to the user.
>
> That's why I asked.  Is this assuming a local server, or a server
> "anywhere".  Is it simply intended to be a well-known name to address the
> *default* VIS server, wherever that exists in the entire routable
> (inter)net.
>
> >
> > Almost in parallel, the designers of the new Infotainment System decide
> to
> > implement the VISS specification and add a VIS Server to the electronic
> > control unit (ECU) that hosts the Infotainment System.
> >
> > Does anyone on the thread have views on how best to address this - or
> > should we remove references to wwwivi and state that implementors will
> > document how to connect to the VIS Server
>
> I still think you might be doing something useful if the specification
> requires (or perhaps recommends?) a well-known name for the default server.
> But I'm trying to really get to the root characteristics of what that thing
> is supposed to mean, before forming a final opinion.
>
> Thanks
> - Gunnar
>
>
> >
> --
> Gunnar Andersson <gandersson@genivi.org>
> Development Lead
> GENIVI Alliance
>
>
>