See also: IRC log
Location: https://lists.w3.org/Archives/Member/internal-autowebplatform/2017Mar/0005.html
(call coordinates)
<scribe> Meeting: RSI
Paul calls roll and introduces topic
Paul: notifications, media,
location being domains we will focus on
... we may settle on another or additional times, a neutral
name (other than ViWi), etc
Ted: call for participation, then
settle on doodle for critical mass, maybe we will have to do 2
different timezone calls
... settle on a working name (RSI is good for now), repo dir
(also rsi)
... Kevin might be interested in being an editor but can't
speak for him. I'm reaching out to Samsung as I understand are
others
Paul: LG is interested but couldn't make today
Gunnar: it sounds like there were some initial differences of opinion and wonder if we should try to separate the issues
Paul: we have done that
... it has gone in circles a bit. we have a submission that is
worth exploring further
... this is in production automobiles
... we want to get broad participation on something useful for
widespread adoption
... some of the hesitation was because we were already on a
path
Gunnar: as you say vehicle signal
spec is continuing and this is focusing on something else
... I don't think anyone is questioning whether this is
viable
Paul: we have additional domains that we have been trying to get going for awhile now
Gunnar: I have not been part of that
Ted gives brief history on media and navigation and how neither are far enough along after considerable time
Gunnar: we want to avoid disparaged approaches for these different "domains"
PatrickL: we have not been able
to open up navigation yet
... we started with the easiest to open, we have some internal
difficulties to overcome
PatrickB: there were use cases on
W3C wiki defined earlier, had someone I know working on a
thesis come up with a clean room design
... it will differ from what we use at VW but will map well
Gunnar: it would have been beneficial to incorporate Genivi's approach
Paul: ultimately we want to align
Gunnar: all I am proposing is we
look at viability of REST+socket as the protocol and then look
at the domains
... I'm surprised location is on the proposed list
Paul: the point is to look at the submission and not ignore Genivi
Ted: we have an early draft from Qing An from Alibaba on LBS which has not received enough review. we have nothing submitted from Genivi nor anyone else on LBS at this point
Gunnar: we can work on a submission
Paul: in ViWi we have car, cdn,
media library and media (services)
... we can look at the main protocol or a particular
domain
... we are purposely not going into signals and letting that
progress but looking at the other domains which have not
evolved within the W3C BG to date
Gunnar: all I'm looking for is to
find a way to work together to find the right APIs
... drawn from multiple sources
... from Genivi perspective we want to avoid having to redesign
things
Rudi: my suggestion for moving
forward is to separate the API from the
transport/protocol
... examine APIs and see how we can present a high level API
for application developers
PatrickB: I think you need the
transport and associated principles with respect to
statefulness etc defined before trying to work on a higher
level API
... I started with the server side on github
... I started with some plugins for the service to be able to
develop production software
... entire framework is implemented and a thin higher level API
works
... as Gunnar illustrated, changing underlying infrastructure
after the fact can be more complicated than taking it into
consideration up front
+1
Gunnar: I don't think anyone
disagrees with implementing and trying things out
... our theory within Genivi is essentially defining an API
once and use across domains
... if you want to make an API perfect
... nobody is disagreeing
... we can try out areas we know we can likely all adopt the
result, ones that would less likely be a problem
PatrickL: we don't really care
which areas to try first. it would be nice to do something more
challenging than simplistic, also something that would be more
interesting
... location fits that bill, media is also of high demand
... if there is another domain you have in mind, please suggest
it
Gunnar: location may be a good candidate
PatrickL: we feel there will be more changes for implementers than for media
Gunnar: we know how to do it on
the vehicle signal side
... maybe REST and sockets are a decent approach and we can
look at bringing our (Genivi) LBS with that model
Paul: are you discussing Genivi's IVI Navigation, POI, LBS Speech or?
https://at.projects.genivi.org/wiki/display/NAV/IVI+Navigation+Home
Sanjeev dropped link https://github.com/OAI/OpenAPI-Specification in WebEx
[review of 2G-VIS, circular discussions, common area]
Ted: the way the BG is structured, people can try new ideas even if they are competing
Paul: next steps? we have a mock server, start working in repo
PatrickB: next I need something
interfacing with it
... further out someone can look at VLC api or something so
they can do actual playback
Sanjeev: I can offer some developer time on clients
Gunnar: are people familiar with mpris? it is interesting for media APIs
https://specifications.freedesktop.org/mpris-spec/latest/
Gunnar: it is pretty widely used in Linux
Paul: call schedule?
Ted: I think weekly until AMM F2F
PatrickB: I'll look at mpris and expand the mock server and reach out to Sanjeev
PatrickB drops link to https://github.com/wzr1337/viwiServer
Sanjeev: we are working with VISS
at OCF
... we are using a templating code based on swagger
... we are building out higher level APIs and spelling them
out, they align well
... exploring more things through code and by next week I may
more to share