Re: VISS / ViWi contrast and review at AGL

Hi Gunnar,

I did assume the blog author would pitch in at some point and clarify. I do
not agree with everything in the blog and some of the comparisons were hard
to understand and categorize.


Some answers inline [sanjeev].



On Jul 2, 2018 6:31 PM, "Gunnar Andersson" <gandersson@genivi.org> wrote:

Thanks Sanjeev,

I fully understand it was all in good faith but I think you took on a
difficult task trying to force common categories into a table that is very
confused, confusing and also misleading.  (I will back that up later in this
email).

So not to criticize your attempt here - the problem is in the table itself
really, and now suddenly it has to be answered.

Before I start, don't think I enjoy this particularly...  I think
introducing this document into the W3C discussion at this point in time was
unfortunate, since the group had collectively decided at the beginning of
this year to stop table-based comparisons like this one.

And the work is focused on next-generation of specifications "version 2", it
is encompassing more and it is focused on convergence.  Why then reintroduce
divisive comparisons?  If you do that, then they will be scrutinized, and
this document is unfortunately filled with nonsense.

Still, we are suddenly in a situation where it can't be left here on the
public list, as if it is an actual useful or correct comparison.  We need to
discuss its content now, it seems.  Since the input document is relatively
old, the author may have learned new things since then, and might not in
fact want to make these exact arguments.  Is everyone, including the author,
being "forced" into a technical debate now?  By whom?

I'd like to propose that people bring forward their own opinions (or rather,
technical arguments).  We were originally asked to "look at this", by a co-
chair in the automotive group, I think, I'm not really sure (?).

For this content here it's really unclear to me who is making technical
arguments to the W3C through this, and if someone stands behind all of them,
only some of them, or none of them.

I'll stop there on that topic.  These working process related topics is
something I think we may discuss further in the working group and it's
better to do it in a separate thread.


I hope this text-based email is understandable, based on Sanjeev's table.
I'll deal with one line at a time.


On Sat, 2018-06-30 at 09:17 +0900, Sanjeev B.A. wrote:
> I read the blog and here is my understanding of the table.
>
> Category      VISS    ViWi
> Filtering & Aggregation support       Filtering on node (not possible on
> several nodes or branches)    Describe a protocol (provides a way for
> multiple node filtering and aggregation)

This is possibly the only line that makes any sense, but from there it is
downhill.  And yet it still does not give a very clear insight.  "not
possible on several nodes or branches" is not very clear.  It *is* surely
possible to set wildcards in several places.  But wildcards are a fairly
blunt instrument, of course.

So... whether that exact capability is the same as "several nodes or
branches" depends on interpretation?  I sort of see little point in trying
to correct all these "one-liner" comparisons, since after reading the
document to the end I can hardly imagine that the intended purpose was to
help the reader to an accurate conclusion.  You cannot put so much
misleading and bad information into a document without having an agenda
behind.

But leaving it is as it is is no good, so I'll complete the picture with my
basic understanding:

The ViWi submission describes a more advanced query model, which is not
surprising since interfaces like browsing Media databases etc. are also the
primary examples of the usage of those queries.  A media database needs a
powerful API, no doubt about it.   (And yes before you jump in, the SAME
query model is also proposed by ViWi for also signals)

For vehicle signals, which is the scope of the VISS (version 1)
specification, there are wildcard matches that can appear anywhere in the
tree, but that's all the specification covers.

I imagine VISS wildcards is probably at the right level for *vehicle
signals* (only), but it's possible that something better might come along.


I would at least note that there are still, currently, a lot of discussions
about this in the wider scope, in W3C both in the "v2" REST based
specification group, as well as in the "Big Data" task force.  Everyone is
trying to get this right, together.



> Privacy Model (Private vs Public)     Access restrictions to signals
> Ability to specify custom signals

What do you mean by "Privacy Model (Private vs Public)", Sanjeev?   And what
is then the VISS and ViWi statements that follow supposed to imply?  (I
guess I'm again asking if you are only writing categories here, or if you
are also putting your name/opinion behind the statements themselves - if so
you might be obliged to explain those).


[sanjeev] I assumed this comparison was based on Private/Public branches
supported in VSS. Again one of the ambiguous categories.


What implies that you cannot specify "custom signals" if you want to?

Whatever the supposed category I just don't see any understandable
comparison of anything.  Maybe the original author is the only one who could
rephrase it, or explain further.

But as anyone would read it straight up, it looks plainly wrong.


[sanjeev] Agreed. One of the many items I found confusing.




> Data Exchange method between W3C Server and Native OS/Platform
> Use high level development languages
> RESTful HTTP calls

Does it imply that you can't use high level development languages when
programming HTTP calls towards a ViWi server?  Or that you can't program a
VISS compatible server in C?

Again not a useful comparison.  It might have been, by actually comparing
the protocols only, but later attempts to do that also got it wrong.


[Sanjeev] agree.



> W3C Server Deployment Model
> One big Server that handle requests
> Stateless

The attempt at a category doesn't help that the table contains nonsense.

The paper seems to move fairly freely between VISS and VSS in places, and
towards the end even specific *implementations* seem to be mixed into the
analysis.

So, step by step:

First, VSS of course implies very little since it is just the signal
database part.


Then, also VISS should not imply a "big" server.

Question to author: Why is the server expected to be "big", exactly?

(Those type of emotive statements are even more prevalent in the text, and
to me they acted as warning bells that the document might not be worth
considering seriously)

And why is it even a single server?  I think if the author had at followed
the W3C work last year he would know how much time was spent discussing
exactly how to best support multiple servers in the version 1 of VISS
specification.   Suffice to say, the ONE THING everyone seemed to agree on
is that it shall of course be possible to have multiple servers, so the
discussion was about how to best support it.

Now, this paper seems to be written quite early, which is why it might be
now out of date input for us.  But I am not aware of anything in VISS (and
much less VSS) that implied, even at the time the paper and table was
created, that there must be only one server!

Then, on the same line, the point about stateless seems just as random.
There is no apple to apple comparison.

Let's review the stateless/stateful aspect:

I believe the VISS v1 protocol only implies that the server keeps internal
state if you set up a subscription to get a continuous feed of updates.  If
you query individual signals, just like you would with a REST like
interface, the server does not need to remember anything.  It is then just
as stateless as a REST (ViWi) query.  It naturally follows the usage model.

And then, the table wrong on the other side too!  Because the ViWi protocol
ALSO includes an extremely similar provision for Pub/Sub as VISS defines (of
course it does, because it is *needed* for vehicle signals, it's perfectly
natural).  And as explained that part of ViWi cannot be stateless!

A PubSub setup simply requires the server to keep state about which
subscriptions were set up (and applied filters).  So in both VISS version 1
protocol and ViWi, the design of stateful/stateless completely follows what
the function requires, which should be obvious to any software engineer.

Therefore that "comparison" is totally bogus.



> Additional Filtering options  Filtering       Filtering, sorting
> Post deployment extensibility Static signals tree not extensible

What exactly implies that the signal tree can't be extended?

(Still not asking you Sanjeev, but the original author, or you can consider
it rhetorical unless you want to make the arguments).



> [VSS] Use JSON objects to communicate

[Is it VSS or VISS being compared?]

Does ViWi not *also* use "JSON objects" to communicate?
So... the author
needs to explain what he means here.


> Ease of "Resource" (as in URI) resolution
> (how to resovle a 'GET' to an actual resource)        Use of AMB ?
> Identification of resources may be a bit heavy going using UUID

I understand you had to try Sanjeev to come up with these categories.
;-)

But this table is not making any coherent comparison, which is the bottom
line I read between the lines in Rudi's question.  Especially here towards
the end it's even more clear this is not really a list of comparable
categories.

Use of AMB?  What?  Where?  The document text elaborates on this and really
regresses into rubbish toward the end.  I won't address it all unless the
document text is also actually seriously brought forward.  But as an
example, there is this supposed AMB reference, and then it seems to be
obsessing about D-Bus?   What is the author writing about now -- is it some
particular (unnamed) implementation?   How is it relevant for comparing
specifications.  Unless the author's intention is suspect, why would you
mislead the reader to think that certain choice of specification or standard
implies implementation details that it does not imply?



> Incomplete - Maybe Transport layer protocol?
> Use of Websocket

ViWi *ALSO* described a websocket protocol, for the same purpose as VISS.

Yes, I still wish I didn't have to address this at all.   The first time I
read this document I felt it was best to ignore it, but instead the working
group was requested to study this, and then suddenly it's on the public
discussion agenda?


[Sanjeev] Agree that some topics are best discussed over IRC or F2F.



Shall we not go back to put our time into something more useful?

Sincerely,
- Gunnar