- From: Gunnar Andersson <gandersson@genivi.org>
- Date: Thu, 06 Apr 2017 08:44:33 +0200
- To: ted@w3.org, public-autowebplatform <public-autowebplatform@w3.org>
- Cc: Klaus Birken Itemis <klaus.birken@itemis.de>
Thanks Ted, On Wed, 2017-04-05 at 17:16 -0400, Ted Guild wrote: > https://www.w3.org/2017/04/05-auto-minutes.html > When reading the minutes, I wish to clarify that at least one times when I said "domain" it might not have been the best choice of word, since it did not refer to different *functional* domains that we were also talking about. (Of course, I'm not a native English speaker). Since it might be misleading in some case, let me elaborate. It's rather that in GENIVI we aspire to define data models and APIs once, and use them across multiple bindings, in what I might call multiple *technical* domains, or environments if you wish. For example, Web-app vs. native app/native service, functions distributed over an in-car network and Internet, smart-device connections, statistics/big-data/cloud-computing- whatever... We rightly spoke about that a socket/service based protocol is very flexible and could in theory cover most or even all of those, but I think it can also be worthwhile to optimize bindings more to each environment. As the most obvious example of this, consider how a compiled native function-call interface could be more performant than reusing a network protocol. What we did not mention, but is also an interesting aspect in the total strategy, is that security/access control is in my opinion also better mapped to native mechanisms for some of the native use cases. Here, consider kernel-implemented access control in contrast to for example exchanging web-style certificates between processes. In today's call we contrasted this theory with good input from other participants - that APIs can be better designed if they know beforehand about the semantics of their execution environment. E.g. APIs designed with knowledge that they are REST APIs, stateless, are best designed with precisely that in mind! So as we continue to extend existing interfaces to more of these technical domains we will learn how well GENIVI succeeds in the "define once" approach. At least we all know that ultimately there is a system where the data exchange needs to come together. So at some place in this chain, semantic differences *will* be resolved, and we at least hope to minimize the necessary manually written translation code. Best Regards, - Gunnar -- Gunnar Andersson <gandersson@genivi.org> Development Lead, GENIVI Alliance
Received on Thursday, 6 April 2017 06:45:22 UTC