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

Re: Short Introduction

From: Jonas Schmidt <jos89@gmx.de>
Date: Tue, 13 Jun 2017 10:20:25 +0200
Message-ID: <CAHChMiepNkKDAjR=x4O-CPORWPHUP7msSpC3T=52cj=znWmXeg@mail.gmail.com>
To: Gunnar Andersson <gandersson@genivi.org>
Cc: public-autowebplatform@w3.org, PHILIPPE COLLIOT <philippe.colliot@mpsa.com>
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+NavigationW3CUseCasesAndGENIVIAPIs
But I am open for any suggestions concerning the naming of the properties.

> 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.

Kind regards,

Jonas


2017-06-06 11:45 GMT+02:00 Gunnar Andersson <gandersson@genivi.org>:

> On Sat, 2017-06-03 at 09:36 +0200, J. Schmidt wrote:
> > Hi Everybody,
>
> Hello Jonas
>
> >
> > My name is Jonas Schmidt (germany). I’m currently doing my bachelor’s
> > degree in business informatics.  I wanted to build an interface
> > specification for my thesis based on the REST architecture pattern that
> > fits into an automotive environment.
>
> 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.
>
> >
> > After some research I recognized the submission of (i.a.) Dr.. Patrick
> > Bartsch that is public on W3C and found the github account and confluence
> > pages of GENIVI Alliance. They attracted my attention while I searched
> use
> > cases for some connectivity projects for cars. I took the GENIVI use
> cases
> > and specified an interface based on the viwi protocol submission.
>
> 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).
>
> What were the assumptions going into your project that made you do it that
> way?
>
> > Now I want to examine the differences between imperative/stateful and
> > stateless approaches while specification and implementation phase.
>
> 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, and looking at the results of a fully- or
> semi-automated conversion to a REST interface.  If you also tried that and
> evaluated the result then I think you would get good answers to the
> question
> at hand here.
>
> In general there should be no reason to start from scratch when going to a
> new domain like Web APIs.  I believe strongly in the idea that the essence
> of APIs should as much as possible be defined once - not uniquely for
> different domains.  But that may need a bit more investigation so I'm
> looking forward to hear your results if you investigate that aspect in
> particular (as opposed to just writing a brand new API).
>
> On the details of that, I haven't looked too deeply at how much client-side
> state is assumed in the GENIVI LBS APIs today, but I would not imagine it
> can be that much.  Most of the time you either want to get the latest value
> of some property, or just perform an operation or otherwise affect
> something
> on the receiver (server) side.
>
> >
> > Patrick asked me if I want to publish my proposal and participate to the
> > BG. So here I am.
> >
> > You can find my proposal on
> > github: https://github.com/j3ss5t/viwiLocationBasedServices
> >
> > Best regards
> >
> > Jonas
>
> Best Regards
> - Gunnar
>
> --
> Gunnar Andersson <gandersson@genivi.org>
> Development Lead
> GENIVI Alliance
>
>
>
>
Received on Tuesday, 13 June 2017 09:12:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 June 2017 09:13:01 UTC