Gerrit repository creation request: apps/agl-service-cloudproxy

Please add also a .gitreview file.

https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps%2Fagl-service-cloudproxy.git;a=shortlog;h=refs%2Fheads%2Fmaster

Hi Scott,

The binding has a configuration where all the cloud service login info is present. The connection to the cloud service is established automatically, at the first time when the sendMessage is called and then kept alive and monitored by the binding. The data passed in sendMessage is just an app-specific payload, that's why it can be of arbitrary string format.

The only thing that is missing on the diagrams is that we add an AGL app ID into V2C message. It is used as a mapping key between the sent V2C and received C2V messages for a local distribution among multiple AGL apps. 

Note sure what you mean under "service selection". The approach that is supposed to be used is the following:

• The chain of cloud services are configured independently to process an inbound vehicle data

• AGL apps send a data to the cloud thru a new AGL service

• The received data is gone thru the built chain of services

In order to send any data to the cloud one needs to connect and authenticate into the cloud hub (i.e. main entry point). That's what a proposed AGL service is aimed to do!

Probably, a vehicle data format may be formally defined, but that's another story and another round of discussions.

/Misha

pointed me at the last V2C meeting minutes, but it's still unclear to me whether the binding is hiding details like service login, or if those need to be put in the JSON passed in sendMessage.  If they don't and the V2C EG members are okay with a just an arbitrary key/value messaging abstraction, I guess I can live with it.  However, I'd suggest moving the service selection to a secondary named parameter (e.g. { "somekey": "somedata", "service": "foo" } or the like) and having it be optional with an additional verb to set the default for the particular user.  Other potential users will have to decide whether the security considerations around access to all cloud providers being multiplexed like this warrants further thought.

I found your presentation from the v2c EG ... (minute 3++)

https://drive.google.com/file/d/1wOOo3pyjHVb_yVMrI_KMt4iKdAjeyWbL/view?usp=sharing