RE: Short Introduction

Hi Jonas,
I’m glad to see someone made such a good job and I’d really like to help you making your work as consistent as possible with the GENIVI LBS APIs ☺
As you may know, defining APIs on a sheet of paper is easy but when it’s needed to concretely implement it, it becomes much more complex.
That’s what my team has faced since years, especially to develop software based on the APIs.
As the maintainer of navigation proof of concepts and the FSA (I’m asanoaozora), I spent a lot of time to make my code more and more robust.
It’s a never ending story, because I do it during my free time and also because navigation is a ‘sprawling’ application (we can extend the features as much as we want).
Recently I’ve refined and extended a significant set of testing software (based on Python), to make the automatic testing easier.

This short introduction is just to point out that, in my opinion, it’s very important to use the same naming for the methods/signals./properties..
Mainly because, with the same naming, it’d be possible to reuse the test scripts and to easily replace the QML based HMI with a HTML/JS based HMI.
I’m definitely not a skilled Web developer like you, so it’d be very fruitful if we could collaborate together on these topics.

What I’d like to do is:

-          To run the navigation middleware (navit+plugins) connected on the DBus

-          To access the LBS APIs with your interface

-          To develop HTML/JS HMI on top of it
We can imagine that the navigation middleware runs on a different device than the HTML clients..

So I’m open to the discussion !

Cordialement, Regards,
[cid:image001.png@01D193D3.0D03A420]
[cid:image002.png@01D2E432.1E6CCBF0]<https://twitter.com/groupePSA>[cid:image003.png@01D2E432.1E6CCBF0]<https://www.facebook.com/groupePSA>[cid:image004.png@01D2E432.1E6CCBF0]<https://www.linkedin.com/company/groupepsa?trk=top_nav_home>[cid:image005.png@01D2E432.1E6CCBF0]<https://www.youtube.com/user/PSAPEUGEOTCITROEN>



Philippe COLLIOT
古璃緒フィリップ
DRD/DSEE/MCSI/IVI
GENIVI LBS-EG lead
Navigation & Map Expert
________________________________
+33 (0)9 66 66 35 65
philippe.colliot@mpsa.com<mailto:philippe.colliot@mpsa.com>
groupe-psa.com<http://www.psa-peugeot-citroen.com/>


Ce message peut contenir des informations confidentielles. S'il ne vous est pas destiné, merci de le détruire et d'informer immédiatement son émetteur. Pour plus d'informations relatives à la confidentialité et à la sécurité veuillez consulter : http://disclaimer.groupe-psa.com<http://disclaimer.groupe-psa.com/>
This message may contain information that is confidential. If you are not the intended recipient, please advise the sender immediately and delete this message. For further information on confidentiality and the risks inherent in electronic communication see http://disclaimer.groupe-psa.com<http://disclaimer.groupe-psa.com/>




De : jos141989@gmail.com [mailto:jos141989@gmail.com] De la part de Jonas Schmidt
Envoyé : mardi 13 juin 2017 10:20
À : Gunnar Andersson
Cc : public-autowebplatform@w3.org; PHILIPPE COLLIOT - U164359
Objet : Re: Short Introduction

>>> Real sender address / Reelle adresse d expedition : jos141989@gmail.com<mailto:jos141989@gmail.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<mailto: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<mailto:gandersson@genivi.org>>
Development Lead
GENIVI Alliance