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

Hi Kevin!

Yes, thanks for your explanations…I think basically I understand the idea behind filter and subscription id. However, I think that we could have an issue when it comes to usability of the api – I don’t think the “bulk” of developers will ever use multiple subscription for the same signal path.
This might resolve itself by having yet another api above (not specified by us) where this would be hidden.
Let’s discuss more in SF – I will arrive on Monday and leave on Friday.

Looking forward meeting you there!
Peter Winzell


From: Gavigan, Kevin [mailto:kgavigan@jaguarlandrover.com]
Sent: Wednesday, October 5, 2016 3:21 PM
To: Peter Winzell
Cc: Paul Boyes; 이원석; Streif, Rudolf (rstreif@jaguarlandrover.com); public-automotive
Subject: Re: Cheching the schedule of FPWD for vehicle signal server spec

Hi Peter,

Thanks very much for the very useful feedback


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.

Its a very good point, will try to remove references to specific languages from spec (as part of moving non essential spec. parts to a separate non-normative supporting information document)



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.

One of the challenges with subscriptions is that we are planning to allow multiple subscriptions for the same path (so for the same set of signals) but with different filter conditions.

For example, we could have a subscription with path engine.rpm with filter requesting an updated value every second and we could have another subscription for engine.rpm, but only want values if it goes above 16000, so to unsubscribe we would need to specify both the path and the filter definition that was passed when the subscription was created. Rather than do this, it seemed easier for the server to return subscriptionId as its unique identifier for the subscription - very similar to the subscription number that e.g. a magazine publisher might assign when posting magazines to its customers.

So we could remove subscriptionId but would need to send path and filter expression to unsubscribe.

Hope this is helpful, perhaps we can discuss these at the F2F in Burlingame?

Very best wishes,

Kev



Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
Software Architect
Connected Infotainment
Electrical, Electronic and Software Engineering (EESE)
Jaguar Land Rover

Mobile: 07990 084866
Email: kgavigan@jaguarlandrover.com<mailto:kgavigan@jaguarlandrover.com>

Office address:
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 5 October 2016 at 11:19, Peter Winzell <Peter.Winzell@melcogot.com<mailto:Peter.Winzell@melcogot.com>> wrote:
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<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
=========================================