W3C home > Mailing lists > Public > public-automotive@w3.org > October 2016

RE: Cheching the schedule of FPWD for vehicle signal server spec

From: Peter Winzell <Peter.Winzell@melcogot.com>
Date: Wed, 5 Oct 2016 10:19:21 +0000
To: Paul Boyes <Paul.Boyes@inrix.com>, 이원석 <wonsuk.lee@etri.re.kr>, "Streif, Rudolf (rstreif@jaguarlandrover.com)" <rstreif@jaguarlandrover.com>
CC: public-automotive <public-automotive@w3.org>
Message-ID: <F151E948D19EFA4A8D984455EF32D51701A5E0405A@melcosse04.meaegot.local>
Hi All!

I have reviewed the Vehicle Signal Server Spec as it stands right now. I have some comments that I need some response to, however, I don’t feel that there are any blockers so we should go ahead and publish.


1)      By referring to a certain type of computer languages all basically based on the Algol(Objective-C has though borrowed some features from SmallTalk) family of languages, we risk on having a debate whether not Ruby, Erlang , Clojure or any other languages that are used on the client side (or on the server side for that matter) are mentioned. My suggestion is to either remove the language parts and just leave native and managed runtime when we explain our wider approach compared to the usual W3C specs which basically only includes web runtime clients.



2)      I think that as the API is specified now with requestid and subscriptionid we need a solid use-case that explains why we have this complicated approach on the client side. One could argue that the server sessionid which identifies each socket instance and the signal path itself would suffice. If the client listen to vehicle.speed the client would know that when vehicle.speed is returned it is relevant - equally when you want to unsubscribe to vehicle.speed you just do that, and the sessionid identifies the client on the server side and the subscription ends.   So, if we get this question I think that it would be good to prepare an answer that includes a specific use-case. I am sure that are some good concrete examples of this - I am , however, failing to come up with one right now. Now, this does not need to be part of the actual spec but I think we need it as an appendix or as a further explanation of the specification.




Br
Peter Winzell

From: Paul Boyes [mailto:Paul.Boyes@inrix.com]
Sent: Wednesday, October 5, 2016 9:07 AM
To: 이원석
Cc: Peter Winzell; public-automotive
Subject: Re: Cheching the schedule of FPWD for vehicle signal server spec

Thanks Peter.  If you and Rudi are good with it run with it.

Paul J. Boyes
206-276-9675

On Oct 5, 2016, at 8:19 AM, 이원석 <wonsuk.lee@etri.re.kr<mailto:wonsuk.lee@etri.re.kr>> wrote:
Great!
If we have done this process in short term. I expect Ted and Kaz will take care of the rest of the work for official publication of the spec! :)

Kind regards,
Wonsuk.

From: Peter Winzell [mailto:Peter.Winzell@melcogot.com]
Sent: Wednesday, October 05, 2016 3:13 PM
To: 이원석 <wonsuk.lee@etri.re.kr<mailto:wonsuk.lee@etri.re.kr>>
Cc: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: RE: Cheching the schedule of FPWD for vehicle signal server spec

Hi Wonsuk!
I think I understand. I will do a review now.

Br
/pw

From: 이원석 [mailto:wonsuk.lee@etri.re.kr]
Sent: Wednesday, October 5, 2016 7:58 AM
To: Peter Winzell
Cc: public-automotive
Subject: RE: Cheching the schedule of FPWD for vehicle signal server spec

Hi. Peter.
It doesn’t mean the consensus for the specific date. It means the consensus for official publication of vehicle signal server spec as a FPWD of W3C.

Below CfC example is from system applications WG. Typically duration of CfC is one week but we have rough consensus to go FPWD in the TPAC meeting so we might be make the term shorter. One thing you should know is W3C only publish the specs in the Tuesday or Thursday of the week. It means there is only two days to publish the FPWD of server spec in the next week.

[1] https://lists.w3.org/Archives/Public/public-sysapps/2014Oct/0030.html


Kind regards,
Wonsuk.

From: Peter Winzell [mailto:Peter.Winzell@melcogot.com]
Sent: Wednesday, October 05, 2016 2:37 PM
To: 이원석 <wonsuk.lee@etri.re.kr<mailto:wonsuk.lee@etri.re.kr>>; public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: RE: Cheching the schedule of FPWD for vehicle signal server spec

Hi Wonsuk!

So, the consensus we are looking for is whether or not the Vehicle Service Spec is in a state for publication on Oct 11 ?

Br
Peter Winzell

From: 이원석 [mailto:wonsuk.lee@etri.re.kr]
Sent: Wednesday, October 5, 2016 3:58 AM
To: public-automotive
Subject: Cheching the schedule of FPWD for vehicle signal server spec

Hi. All.
In the last TPAC meeting we had a consensus to publish the FPWD for vehicle signal server spec at 11th October. Because we really want to do this before GENIVI AMM meeting in Burlingame. To achieving this, we need to have CfC(Call for Consensus) process for the spec as soon as possible.

Chairs! (Paul, Rudi and Peter)
I guess it would be perfect if you do this with short term CfC today or tomorrow!

Thanks!

Kind regards,
Wonsuk.
=========================================
이 원 석 (Wonsuk, Lee) / Senior Researcher, Ph.D
한국전자통신연구원 표준연구센터(Protocol Engineering Center, ETRI)
Mobile: +82-10-5800-3997   Office: +82-42-860-6104
E-mail: wonsuk.lee@etri.re.kr<mailto:wonsuk.lee@etri.re.kr>
http://www.wonsuk73.com/, twitter: @wonsuk73
=========================================

Received on Wednesday, 5 October 2016 10:19:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:52 UTC