Merge pull request #3 from UlfBj/cv-opt

Tutorial links update.

tutorial/config.toml

@@ -1,20 +1,20 @@
-baseURL = "https://w3c.github.io/automotive-viss2/"
+baseURL = "https://covesa.github.io/vissr/"
 languageCode = "en-us"
-title = "W3C VISSv2 Reference Implementation"
+title = "COVESA VISSv2 Reference Implementation (vissr)"
 theme = "learn"
 publishDir = "../docs"
 [params]
   # Change default color scheme with a variant one. Can be "red", "blue", "green".
   themeVariant = "blue"
   disableInlineCopyToClipBoard = true
-  editURL = "https://github.com/w3c/automotive-viss2/edit/master/tutorial/content/"
+  editURL = "https://github.com/covesa/vissr/edit/master/tutorial/content/"
   disableLandingPageButton = true
 
 
 [[menu.shortcuts]]
 name = "<i class='fab fa-github'></i> Github repo"
 identifier = "ds"
-url = "https://github.com/w3c/automotive-viss2"
+url = "https://github.com/covesa/vissr"
 weight = 10
 
 # Generation of JSON index to allow search

tutorial/content/_index.md

@@ -1,14 +1,14 @@
 ---
-title: "W3C Vehicle Information Service Specification ver 2 Reference Implementation Tutorial"
+title: "COVESA Vehicle Information Service Specification ver 2 Reference Implementation Tutorial"
 ---
-## W3C Vehicle Information Service Specification ver 2 Reference Implementation Tutorial
+## COVESA Vehicle Information Service Specification ver 2 Reference Implementation Tutorial
 
-The W3C VISSv2 specification, soon to become a W3C standard, is developed at the [W3C/automotive github](https://github.com/w3c/automotive).
+The COVESA VISSv2 specification is developed at the [COVESA/automotive github](https://github.com/COVESA/vehicle-information-service-specification).
 A reference implementation in the form of a server that exposes an interface according to the specification is developed on this repo.
 
 Also found on this repo are implementations of other components that are needed to realize a communication tech stack that reaches from clients through the server and to the underlying vehicle system interface.
 
-![VISSv2 communication tech stack](/automotive-viss2/images/WAII-tech-stack.jpg?width=40pc)
+![VISSv2 communication tech stack](/vissr/images/WAII-tech-stack.jpg?width=40pc)
 
 These software components (SwCs) can be categorized as follows:
 * server

tutorial/content/build-system/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "WAII Build System"
+title: "VISSR Build System"
 ---
 
 ## Installing Golang
@@ -38,11 +38,11 @@ If there is any calls to the "github.com/akamensky/argparse" lib then it is used
 As the configurations have a default it is always possible to run it without adding any comand line configuration input.
 The configuration possibilities of the different SwCs are described in the respective chapters of this tutorial.
 
-The server consists of several "actors", see the [README](https://github.com/w3c/automotive-viss2) Overview chapter.
+The server consists of several "actors", see the [README](https://github.com/covesa/vissr) Overview chapter.
 These used to be built as separate processes that communicated over the Websockets protocol.
 To simplify the building process of thesesoftware components the script W3CServer.sh was created.
 After the refactoring of these SwCs into one process with ech actor running as a separate thread,
-it became more convenient to build without this script, but it is still [avaliable](https://github.com/w3c/automotive-viss2/blob/master/W3CServer.sh).
+it became more convenient to build without this script, but it is still [avaliable](https://github.com/covesa/vissr/blob/master/W3CServer.sh).
 For more details, see the "Multi-process vs single-process server implementation" chapter in the README.
 
 There are multiple Software components on this repo, such as feeders, simulators, the DCT tool that are to be built as separate excutables.
@@ -89,8 +89,8 @@ For more information see https://github.com/golang/go/wiki/Modules#when-should-i
 
 ## Docker
 
-The server can also be built and launched using docker and docker-compose, see the [Docker README](https://github.com/w3c/automotive-viss2/tree/master/docker).
+The server can also be built and launched using docker and docker-compose, see the [Docker README](https://github.com/covesa/vissr/tree/master/docker).
 Current example builds and runs using the redis state storage together with an implementation of the feeder interfacing 
-the remotiveLabs broker in the cloud.[feeder-rl](https://github.com/w3c/automotive-viss2/tree/master/feeder/feeder-rl) .
+the remotiveLabs broker in the cloud.[feeder-rl](https://github.com/covesa/vissr/tree/master/feeder/feeder-rl) .
 
 

tutorial/content/client/_index.md

@@ -5,7 +5,7 @@ title: "VISSv2 Clients"
 There are a number of different clients avaliable on this repo in the client/client-1.0 directory.
 
 ## Compression client
-The [compression client](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/compress_client/compress_client.go) can be used for testing three payload compression variants.
+The [compression client](https://github.com/covesa/vissr/blob/master/client/client-1.0/compress_client/compress_client.go) can be used for testing three payload compression variants.
 * Proprietary compression algorithm
 * Protobuf encoding, level 1
 * Protobuf encoding, level 2
@@ -16,76 +16,77 @@ Due to its strong dependence on the payload format it might require rewrites if/
 It is not kept up to date on this and is therefore likely to crash if an unsupported payload is applied.
 
 ### Protobuf encoding
-The encoding uses the VISSv2messages.proto file found [here](https://github.com/w3c/automotive-viss2/tree/master/protobuf).
+The encoding uses the VISSv2messages.proto file found [here](https://github.com/covesa/vissr/tree/master/protobuf).
 The server supports this only for the Websocket protocol, where the websocket transport manager encodes payloads before sending them,
 and decodes payloads directly after receiving them. The client follows the same encoding/decoding behavior,
 so that the use of protobuf encoding is abstracted before other layers in both the server and the client get access to the payloads.
 Two levels of protobuf encoding are available, level one in which paths and timestamps have the standardized text format,
 and level two where these fields are compressed.
 
 #### Level 2
-Level 2 compresses the VSS paths by using the [VSS path list](/automotive-viss2/server#pathlist-file-generation) as a lookup table.
+Level 2 compresses the VSS paths by using the [VSS path list](/vissr/server#pathlist-file-generation) as a lookup table.
 Instead of using the string paths in the encoded payload the index into the array is used.
 Finding the index in the array for a given path is done by applying a binary search, as the array paths are sorted by the server.
 Going the other way, the array is simply indexed by the integer value from the protobuf encoded payload.
-The string based timestamps are replaced by an int32 as shown in the CompressTS() procedure found in [computils.go](https://github.com/w3c/automotive-viss2/blob/master/utils/computils.go).
+The string based timestamps are replaced by an int32 as shown in the CompressTS() procedure found in [computils.go](https://github.com/covesa/vissr/blob/master/utils/computils.go).
 Level 2 achieves compression rates of around 5 or better.
 
 ## gRPC client
-The gRPC implementation uses the protobuf encoding in the VISSv2messages.proto file found [here](https://github.com/w3c/automotive-viss2/tree/master/grpc_pb).
+The gRPC implementation uses the protobuf encoding in the VISSv2messages.proto file found [here](https://github.com/covesa/vissr/tree/master/grpc_pb).
 The server currently only supports the protobuf level 1 encoding.
 
 ## MQTT client
-The [MQTT client]() implements the application level protocol described in the [specification](https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Transport.html#application-level-protocol).
+The [MQTT client](https://github.com/UlfBj/vissr/tree/master/client/client-1.0/mqtt_client) implements the application level protocol described in the
+[specification](https://raw.githack.com/COVESA/vehicle-information-service-specification/main/spec/VISSv2_Transport.html#application-level-protocol).
 
 ## CSV client
 The [CSV client]() is developed for testing the [curve logging algorithm](https://www.geotab.com/blog/gps-logging-curve-algorithm/) that Geotab has opened for public cuse.
-A client can equest it to be aplied to data by using a [filter](https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Core.html#curvelog-filter-operation) option.
+A client can equest it to be aplied to data by using a [filter](https://raw.githack.com/COVESA/vehicle-information-service-specification/main/spec/VISSv2_Core.html#curvelog-filter-operation) option.
 
 It generates a comma separated (CSV) file in which it saves the curve logged data that it has reuested from the server.
 The CSV format makes it easy to import it into an Excel sheet and visualize it as a graph which allows it e. g. to be compared with the original, non-curved data.
 
 ## Java script clients
 There are a few clients that are written in Javascript, and thus when started opens in a browser.
 Thes clients can be quite handy for quick testing of the server functionality.
-Example payloads that can be used as input are found in the [appclient_commands.txt](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/appclient_commands.txt) file.
+Example payloads that can be used as input are found in the [appclient_commands.txt](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/appclient_commands.txt) file.
 
 ### HTTP client
-The [HTTP Client](file:///home/ubjorken/Proj/w3c/WAII/client/client-1.0/Javascript/httpclient.html)
+The [HTTP Client](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/httpclient.html)
 requires the server IP address/URL to be written into the field for it, and the IP address button to be pushed.
 Thereafter paths can be written into the Get field, followed by a push of the Get button.
 In the case of the client writing a value to the server, the path is written into the Set field, with the value in the following field, before pushing the Post button.
 If the data associated with the path is access controlled, then the access token that must have been obtained via the dialogues with the two autorization servers
 must first be written into the field for the token. Klicking the button to the right of it preserves the token for use in multple requests.
 
 ### Websocket client
-The [Websocket Client](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/wsclient_uncompressed.html)
+The [Websocket Client](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/wsclient_uncompressed.html)
 requires the server IP address/URL to be written into the field for it, and the IP address button to be pushed.
 Thereafter JSON based payloads can be written into the Sed field, followed by a push of the Send button.
 
 ### Websocket client (using compression)
-The [Websocket Client](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/wsclient_compressed.html)
+The [Websocket Client](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/wsclient_compressed.html)
 requires the server IP address/URL to be written into the field for it, and the IP address button to be pushed.
 Thereafter JSON based payloads can be written into the Sed field, followed by a push of the Send button.
 The difference to the uncompressed Websocket client is that this client opens a Websocket session with the erver in which it requests a session in which
 proprietary compression is applied to the payloads (see chapter above).
 
 ### Access Grant Token Server client
-The [AGT client](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/agtclient.html)
+The [AGT client](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/agtclient.html)
 requests an Access Grant Token from the Access Grant Token server.
 
 It requires the AGT server IP address/URL to be written into the field for it, and the Server IP button to be pushed.
 In the leftmost field below "agtserver" (no quotes) must be written, then in the rightmost field a request payload shall be written.
-A payload example can be found in the [appclient_commands.txt](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/appclient_commands.txt) file.
+A payload example can be found in the [appclient_commands.txt](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/appclient_commands.txt) file.
 The proof value must be "ABC" for a positive validation, in which case an Access Grant token is returned.
 
 ### Access Token Server client
-The [AT client](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/atclient.html)
+The [AT client](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/atclient.html)
 requests an Access Token from the Access Token server.
 
 It requires the AT server IP address/URL to be written into the field for it, and the Server IP button to be pushed.
 In the leftmost field below "atserver" (no quotes) must be written, then in the rightmost field a request payload shall be written.
-A payload example can be found in the [appclient_commands.txt](https://github.com/w3c/automotive-viss2/blob/master/client/client-1.0/Javascript/appclient_commands.txt) file.
+A payload example can be found in the [appclient_commands.txt](https://github.com/covesa/vissr/blob/master/client/client-1.0/Javascript/appclient_commands.txt) file.
 The token that is provided in the request must include an Access Grant token from the response of a successful reuquest to the AGT server.
 
 ## Clients on other repos

tutorial/content/datastore/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "WAII Data Storage"
+title: "VISSR Data Storage"
 ---
 
 Two realizations of data storage are available on the [COVESA/CCS-components Github](https://github.com/COVESA/ccs-components),
@@ -14,6 +14,6 @@ It may be a bit confusing that sometimes this is referred to as "data store/stor
 The latter name is legacy from a previous COVESA project, the Cloud & Connected Services project, while the former has emerged later in the COVESA architecture group work.
 An argument for keeping both could be to say that the state storage refers to a storage that only keeps the latest value of a signal,
 while the data store refers to a more general database that can also keep time series of values of a signal.
-There are two scenarios where the VISSv2 server operates on time series data, [curve logging](https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Core.html#curvelog-filter-operation),
-and [historic data](https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Core.html#history-filter-operation),
+There are two scenarios where the VISSv2 server operates on time series data, [curve logging](https://raw.githack.com/covesa/vehicle-information-service-specification/main/spec/VISSv2_Core.html#curvelog-filter-operation),
+and [historic data](https://raw.githack.com/covesa/vehicle-information-service-specification/main/spec/VISSv2_Core.html#history-filter-operation),
 but in this server implementation these data series is temporarily stored within the server, so a "state storage" functionality is sufficient for its needs.

tutorial/content/datastore/redis/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "WAII Redis"
+title: "VISSR Redis"
 ---
 
 ## Redis state storage

tutorial/content/datastore/sqlite/_index.md

@@ -1,11 +1,11 @@
 ---
-title: "WAII SQLite"
+title: "VISSR SQLite"
 ---
 
 ## SQLite state storage
 When an SQLite database is used as the state storage it is necessary to prepopulate it with one row for each VSS treeleaf node, having the path name as the key.
 To do this there is a [statestorage_mgr](https://github.com/COVESA/ccs-components/tree/master/statestorage/sqlImpl) that takes a file containing a list of all the pathnames,
 "vsspathlist.json" as input. This file is generated by the server at startup, taking the paths from the VSS tree that it has access to.
 
-This SQLite DB file then needs to be moved to the WAII/server/visv2server/serviceMgr directory, where it should have the name "statestorage.db"
+This SQLite DB file then needs to be moved to the vissr/server/visv2server/serviceMgr directory, where it should have the name "statestorage.db"
 (if server configuration is not changed to another name).

tutorial/content/feeder/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "WAII Feeders"
+title: "VISSR Feeders"
 ---
 
 A feeder is a Sw component that needs to implement three tasks:
@@ -12,13 +12,13 @@ which spawns two threads that implement the respective interface task.
 The architecture shown handle all its communication with the server via the state storage.
 This leads to a polling paradigm and thus a potential latency and performance weakness.
 This architecture is therefore not found on the master branch, but available on the datastore-poll branch.
-![Feeder Sw architecture, unoptimized polling](/automotive-viss2/images/feeder-sw-design-v1.jpg?width=50pc)
+![Feeder Sw architecture, unoptimized polling](/vissr/images/feeder-sw-design-v1.jpg?width=50pc)
 * Figure 1. Feeder software architecture unoptimized polling
 
 An improved architecture that eliminates the mentioned weaknesses for data flowing in the direction from the server to the feeder (i. e client write requests)
 is shown in figure 2. For write requests the server communicates directly over an IPC channel with the feeder, thus removing the need for the feeder to poll
 the state storage to find new write requests.
-![Feeder Sw architecture, optimized polling](/automotive-viss2/images/feeder-sw-design-v2.jpg?width=50pc)
+![Feeder Sw architecture, optimized polling](/vissr/images/feeder-sw-design-v2.jpg?width=50pc)
 * Figure 2. Feeder software architecture optimized polling
 
 A feeder implementing the optimized polling version of the SwA is found at the master branch.
@@ -32,15 +32,15 @@ The instructions for how to do this is encoded into one or more configuration fi
 There are two versions of the feeder instructions, being used in template feederv1 and feederv2, respectively.
 
 In version 1 this file only contains a signal name mapping, while version 2 supports also scaling instructions.
-For more about the telpate feeders, see the README in [feeder-template](https://github.com/w3c/automotive-viss2/tree/master/feeder/feeder-template) directory.
+For more about the telpate feeders, see the README in [feeder-template](https://github.com/covesa/vissr/tree/master/feeder/feeder-template) directory.
 
 An OEM wanting to deploy the VISSv2 tech stack needs to implement the Vehicle interface of the feeder, e. g. to implement a CAN bus interface.
 In the template feeders the Vehicle interface contains a minimal signal simulator that generates random values for the signals it is configured to support.
 All  of that code should be removed and replaced by the code implementing the new interface client.
 
-Besides the feeder templates there is also an [rl-feeder](https://github.com/w3c/automotive-viss2/tree/master/feeder/feeder-rl)
+Besides the feeder templates there is also an [rl-feeder](https://github.com/covesa/vissr/tree/master/feeder/feeder-rl)
 where the Vehicle interface is implemented to connect to a RemotiveLabs broker.
 [RemotiveLabs](https://remotivelabs.com/) has a public cloud version of its broker that can be used to replay trip data available in VSS format.
 
-There is also an External Vehicle Interface Client [EVIC](https://github.com/w3c/automotive-viss2/tree/master/feeder/feeder-evic)
+There is also an External Vehicle Interface Client [EVIC](https://github.com/covesa/vissr/tree/master/feeder/feeder-evic)
 feeder that enables the interface client to be implemented in a separate executable.