W3C home > Mailing lists > Public > public-autowebplatform@w3.org > June 2017

Re: Short Introduction

From: Gunnar Andersson <gandersson@genivi.org>
Date: Tue, 13 Jun 2017 13:35:45 +0200
Message-ID: <1497353745.27440.5.camel@genivi.org>
To: Jonas Schmidt <jos89@gmx.de>
Cc: public-autowebplatform@w3.org, PHILIPPE COLLIOT <philippe.colliot@mpsa.com>
On Tue, 2017-06-13 at 10:20 +0200, Jonas Schmidt wrote:
> Hi Gunnar,
> > But that's assuming that the REST architecture pattern fits into an
> > automotive environment... 
> > ;-)   I'm just kidding - it's a good thesis subject, I'm sure.
> I hope so. :D
> > So you used the use-cases but not the GENIVI LBS APIs?  It seems an
> > unnecessary reinvention to not reuse the names of properties and 
> such that
> > many others are used to?  Also if you did, it would be easier to draw
> the interesting thesis conclusions in my opinion (see below).
> Actually I used the terms described in the single descriptions of the use
> cases and the names of the functions mentioned in the right column of
> https://at.projects.genivi.org/wiki/display/NAV/IVI+NavigationW3CUseCasesA
> But I am open for any suggestions concerning the naming of the properties.

Good, and I think if you look at the actual APIs you will have a lot more
detail to work from than only the use case page.

> > What were the assumptions going into your project that made you do it
> that
> > way?
> I wanted to create micro services that are "as restful as" possible. I
> tried to include concepts like separation of concerns etc. My proposal is
> just a first draft so as I sad I'm open for any suggestions.
> > This is good and similar to what GENIVI has been looking at in this area
> > too.  Essentially we are interested in investigating the result of
> taking a
> > comprehensive LBS API that has been published, most of which are of
> Remote-Procedure-Call + Signal type...
> I think you're talking about the xml api specification of the GENIVI API
> which you want to use for api generation. (did I get this right) To
> be honest: I did not examined the xml yet.

Yes but it should be much easier to read in Franca IDL format (.fidl), and
nowadays the Franca definition is also the official source code for the
GENIVI LBS APIs.  It replaces the older XML definitions.

So if you want to read the straight-up API files, see [1].

Also as an example of what we can do there is also this test generation at
[2].   That project takes the LBS APIs in Franca and generates C++ headers
and classes.  I don't claim it's a final and fully usable C++ format for
programming, but more as a proof of concept.  

After running Doxygen over the C++ code, you get documentation that is quite
readable.  It obviously has some C++ flavor but it provides it in a nicely
structured format.

The C++/Doxygen generation is just an example.  If I get clear indication
from either Web or LBS people about what format we _want_ to get out, based
on the Franca input, then it should not be a too big deal to modify code
generators to make that happen.  I actually think it will be a lot easier 
than the C++ was.

By the way, this python generation framework is an alternative. We're also
looking to extend the Franca tooling that is in Eclipse environment
similarly and the aim of that is getting both Web APIs and relevant binding
code directly out of the IDL definitions.

I'm sure Philippe Colliot can guide you to additional documentation, or
answer more questions on LBS documentation and such.

- Gunnar

[1] https://github.com/GENIVI/navigation/tree/master/api/franca/navigation
[2] https://gunnarx.github.io/pyfrancagen/annotated.html

> [trimmed]

Gunnar Andersson <gandersson@genivi.org>
Development Lead
GENIVI Alliance
Received on Tuesday, 13 June 2017 11:36:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:52 UTC