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

*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>
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]
> *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> 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! J
>
>
>
> Kind regards,
>
> Wonsuk.
>
>
>
> *From:* Peter Winzell [mailto:Peter.Winzell@melcogot.com
> <Peter.Winzell@melcogot.com>]
> *Sent:* Wednesday, October 05, 2016 3:13 PM
> *To:* 이원석 <wonsuk.lee@etri.re.kr>
> *Cc:* public-automotive <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 <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
> <Peter.Winzell@melcogot.com>]
> *Sent:* Wednesday, October 05, 2016 2:37 PM
> *To:* 이원석 <wonsuk.lee@etri.re.kr>; public-automotive <
> 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 <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 <wonsuk.lee@etri.re.kr>*
>
> *http://www.wonsuk73.com/ <http://www.wonsuk73.com/>*, twitter: @wonsuk73
>
> =========================================
>
>
>
>