@ondewo/csi-client-angular 2.3.1

package/index.d.ts

@@ -0,0 +1,5 @@
+/**
+ * Generated bundle index. Do not edit.
+ */
+/// <amd-module name="@ondewo/csi-client-angular" />
+export * from './public-api';

package/ondewo-csi-api/README.md

@@ -0,0 +1,91 @@
+<p align="center">
+    <a href="https://www.ondewo.com">
+      <img alt="ONDEWO Logo" src="https://raw.githubusercontent.com/ondewo/ondewo-logos/master/github/ondewo_logo_github_2.png"/>
+    </a>
+</p>
+
+# ONDEWO CSI APIs
+
+This repository contains the original interface definitions of public ONDEWO APIs that support gRPC protocols. Reading the original interface definitions can provide a better understanding of ONDEWO APIs and help you to utilize them more efficiently. You can also use these definitions with open source tools to generate client libraries, documentation, and other artifacts.
+
+The core componenets of all the client libraries are built directly from files in this repo using [the proto compiler.](https://github.com/ondewo/ondewo-proto-compiler)
+
+For an end-user, the APIS in this repo function mostly as documentation for the endpoints. For specific implementations, look in the following repos for working implementations:
+* [Python](https://github.com/ondewo/ondewo-csi-client-python)
+
+Please note that some of these implementations are works-in-progress. The repo will make clear the status of the implementation.
+
+## Overview
+
+ONDEWO APIs use [Protocol Buffers](https://github.com/google/protobuf) version 3 (proto3) as their Interface Definition Language (IDL) to define the API interface and the structure of the payload messages. The same interface definition is used for gRPC versions of the API in all languages.
+
+There are several ways of accessing APIs:
+
+1.  Protocol Buffers over gRPC: You can access APIs published in this repository through [GRPC](https://github.com/grpc), which is a high-performance binary RPC protocol over HTTP/2. It offers many useful features, including request/response multiplex and full-duplex streaming.
+
+2.  ONDEWO Client Libraries:
+You can use these libraries to access ONDEWO Cloud APIs. They are based on gRPC for better performance and provide idiomatic client surface for better developer experience.
+
+## Discussions
+
+Please use the issue tracker in this repo for discussions about this API, or the issue tracker in the relevant client if it is language-specific.
+
+## Repository Structure
+
+```
+.
+├── CONTRIBUTING.md
+├── LICENSE
+├── ondewo
+│   ├── csi
+│   │   ├── conversation.proto
+├── README.md
+└── RELEASE.md
+```
+
+## Generate gRPC Source Code
+
+API client libraries can be built directly from files in this repo using [the proto compiler.](https://github.com/ondewo/ondewo-proto-compiler)
+
+
+Automatic Release Process
+------------------
+The entire process is automated to make development easier. The actual steps are simple:
+
+TODOs in Pull Request before the release:
+
+ - Update the Version number inside the Makefile
+
+ - Check if RELEASE.md is up-to-date
+
+TODOs after Pull Request was merged in:
+
+ - Checkout master:
+    ```bash
+    git checkout master
+    ```
+ - Pull the new stuff:
+    ```bash
+    git pull
+    ```
+ - Release:
+    ```bash
+    make ondewo_release
+    ```
+
+The   ``` make ondewo_release``` command can be divided into 5 steps:
+
+- cloning the devops-accounts repository and extracting the credentials
+- creating and pushing the release branch
+- creating and pushing the release tag
+- creating the GitHub release
+
+The variable for the GitHub Access Token is inside the Makefile,
+but the value is overwritten during ``` make ondewo_release```, because
+it is passed from the devops-accounts repo as an argument to the actual ```release``` command.
+
+Proto Documentation
+-------------------
+
+Documentation for the .proto files is generated automatically when there is a pullrequest or push
+to master. It is located in the branch [gh-pages](https://github.com/ondewo/ondewo-csi-api/tree/gh-pages).

package/ondewo-csi-api/google/ads/googleads/README.md

@@ -0,0 +1,21 @@
+# Google Ads API - proto definitions
+
+This folder contains the [protocol
+buffer](https://developers.google.com/protocol-buffers/) definitions for the
+[Google Ads API](https://developers.google.com/google-ads/api/). To use this
+API, we encourage you to take a look at our [official client
+libraries](https://developers.google.com/google-ads/api/docs/client-libs) for
+Java, Ruby, PHP, or .NET. Refer to the
+[Quickstart](https://developers.google.com/google-ads/api/docs/first-call/overview)
+to learn how to make your first API call.
+
+To develop in a programming language without an official client library, refer
+to the [API Concepts
+Guide](https://developers.google.com/google-ads/api/docs/concepts/overview) and
+consult these protocol buffer definitions as a reference when constructing API
+requests.
+
+Use [the official Google Ads API
+forum](https://groups.google.com/d/forum/adwords-api) to request an official
+client library in another programming language, report bugs, request new
+features in the Google Ads API, or provide feedback.

package/ondewo-csi-api/google/api/README.md

@@ -0,0 +1,5 @@
+This folder contains the schema of the configuration model for the API services
+platform.
+
+**Note**: Protos under this directory are in Alpha status, and therefore are
+subject to breaking changes.

package/ondewo-csi-api/google/api/servicecontrol/README.md

@@ -0,0 +1,126 @@
+Google Service Control provides control plane functionality to managed services,
+such as logging, monitoring, and status checks. This page provides an overview
+of what it does and how it works.
+
+## Why use Service Control?
+
+When you develop a cloud service, you typically start with the business
+requirements and the architecture design, then proceed with API definition
+and implementation. Before you put your service into production, you
+need to deal with many control plane issues:
+
+* How to control access to your service.
+* How to send logging and monitoring data to both consumers and producers.
+* How to create and manage dashboards to visualize this data.
+* How to automatically scale the control plane components with your service.
+
+Service Control is a mature and feature-rich control plane provider
+that addresses these needs with high efficiency, high scalability,
+and high availability. It provides a simple public API that can be accessed
+from anywhere using JSON REST and gRPC clients, so when you move your service
+from on-premise to a cloud provider, or from one cloud provider to another,
+you don't need to change the control plane provider.
+
+Services built using Google Cloud Endpoints already take advantage of
+Service Control. Cloud Endpoints sends logging and monitoring data
+through Google Service Control for every request arriving at its
+proxy. If you need to report any additional logging and monitoring data for
+your Cloud Endpoints service, you can call the Service Control API directly
+from your service.
+
+The Service Control API definition is open sourced and available on
+[GitHub](https://github.com/googleapis/googleapis/tree/master/google/api/servicecontrol).
+By changing the DNS name, you can easily use alternative implementations of
+the Service Control API.
+
+## Architecture
+
+Google Service Control works with a set of *managed services* and their
+*operations* (activities), *checks* whether an operation is allowed to proceed,
+and *reports* completed operations. Behind the scenes, it leverages other
+Google Cloud services, such as
+[Google Service Management](/service-management),
+[Stackdriver Logging](/logging), and [Stackdriver Monitoring](/monitoring),
+while hiding their complexity from service producers. It enables service
+producers to send telemetry data to their consumers. It uses caching,
+batching, aggregation, and retries to deliver higher performance and
+availability than the individual backend systems it encapsulates.
+
+<figure id="fig-arch" class="center">
+<div style="width: 70%;margin: auto">
+  <img src="/service-control/images/arch.svg"
+    alt="The overall architecture of a service that uses Google Service Control.">
+</div>
+<figcaption><b>Figure 1</b>: Using Google Service Control.</figcaption>
+</figure>
+
+The Service Control API provides two methods:
+
+* [`services.check`](/service-control/reference/rest/v1/services/check), used for:
+    * Ensuring valid consumer status
+    * Validating API keys
+* [`services.report`](/service-control/reference/rest/v1/services/report), used for:
+    * Sending logs to Stackdriver Logging
+    * Sending metrics to Stackdriver Monitoring
+
+We’ll look at these in more detail in the rest of this overview.
+
+## Managed services
+
+A [managed service](/service-management/reference/rest/v1/services) is
+a network service managed by
+[Google Service Management](/service-management). Each managed service has a
+unique name, such as `example.googleapis.com`, which must be a valid
+fully-qualified DNS name, as per RFC 1035.
+
+For example:
+
+* Google Cloud Pub/Sub (`pubsub.googleapis.com`)
+* Google Cloud Vision (`vision.googleapis.com`)
+* Google Cloud Bigtable (`bigtable.googleapis.com`)
+* Google Cloud Datastore (`datastore.googleapis.com`)
+
+Google Service Management manages the lifecycle of each service’s
+configuration, which is used to customize Google Service Control's behavior.
+Service configurations are also used by Google Cloud Console
+for displaying APIs and their settings, enabling/disabling APIs, and more.
+
+## Operations
+
+Google Service Control uses the generic concept of an *operation*
+to represent the
+activities of a managed service, such as API calls and resource usage. Each
+operation is associated with a managed service and a specific service
+consumer, and has a set of properties that describe the operation, such as
+the API method name and resource usage amount. For more information, see the
+[Operation definition](/service-control/rest/v1/Operation).
+
+## Check
+
+The [`services.check`](/service-control/reference/rest/v1/services/check)
+method determines whether an operation should be allowed to proceed
+for a managed service.
+
+For example:
+
+* Check if the consumer is still active.
+* Check if the consumer has enabled the service.
+* Check if the API key is still valid.
+
+By performing multiple checks within a single method call, it provides
+better performance, higher reliability, and reduced development cost to
+service producers compared to checking with multiple backend systems.
+
+## Report
+
+The [`services.report`](/service-control/reference/rest/v1/services/report)
+method reports completed operations for
+a managed service to backend systems, such as logging and monitoring. The
+reported data can be seen in Google API Console and Google Cloud Console,
+and retrieved with appropriate APIs, such as the Stackdriver Logging and
+Stackdriver Monitoring APIs.
+
+## Next steps
+
+* Read our [Getting Started guide](/service-control/getting-started) to find out
+  how to set up and use the Google Service Control API.

package/ondewo-csi-api/google/api/servicemanagement/README.md

@@ -0,0 +1,102 @@
+Google Service Management manages a set of *services*. Service
+Management allows *service producers* to
+publish their services on Google Cloud Platform so that they can be discovered
+and used by *service consumers*. It also handles the tasks of tracking
+service lifecycle and programming various backend systems -- such as
+[Stackdriver Logging](https://cloud.google.com/stackdriver),
+[Stackdriver Monitoring](https://cloud.google.com/stackdriver) -- to support
+the managed services.
+
+If you are a service producer, you can use the Google Service Management API
+and [Google Cloud SDK (gcloud)](/sdk) to publish and manage your services.
+Each managed service has a service configuration which declares various aspects
+of the service such as its API surface, along with parameters to configure the
+supporting backend
+systems, such as logging and monitoring. If you build your service using
+[Google Cloud Endpoints](https://cloud.google.com/endpoints/), the service
+configuration will be handled automatically.
+
+If you are a service consumer and want to use a managed service, you can use the
+Google Service Management API or [Google Cloud Console](https://console.cloud.google.com)
+to activate the
+service for your [Google developer project](https://developers.google.com/console/help/new/),
+then start using its APIs and functions.
+
+## Managed services
+
+REST URL: `https://servicemanagement.googleapis.com/v1/services/{service-name}` <br />
+REST schema is defined [here](/service-management/reference/rest/v1/services).
+
+A managed service refers to a network service managed by
+Service Management. Each managed service has a unique name, such as
+`example.googleapis.com`, which must be a valid fully-qualified DNS name, as per
+RFC 1035.
+
+A managed service typically provides some REST APIs and/or other
+functions to their service consumers, such as mobile apps or cloud services.
+
+Service producers can use methods, such as
+[services.create](/service-management/reference/rest/v1/services/create),
+[services.delete](/service-management/reference/rest/v1/services/delete),
+[services.undelete](/service-management/reference/rest/v1/services/undelete),
+to manipulate their managed services.
+
+## Service producers
+
+A service producer is the Google developer project responsible for publishing
+and maintaining a managed service. Each managed service is owned by exactly one
+service producer.
+
+## Service consumers
+
+A service consumer is a Google developer project that has enabled and can
+invoke APIs on a managed service. A managed service can have many service
+consumers.
+
+## Service configuration
+
+REST URL: `https://servicemanagement.googleapis.com/v1/services/{service-name}/configs/{config_id}` <br />
+REST schema is defined [here](/service-management/reference/rest/v1/services.configs).
+
+Each managed service is described by a service configuration which covers a wide
+range of features, including its name, title, RPC API definitions,
+REST API definitions, documentation, authentication, and more.
+
+To change the configuration of a managed service, the service producer needs to
+publish an updated service configuration to Service Management.
+Service Management keeps a history of published
+service configurations, making it possible to easily retrace how a service's
+configuration evolved over time. Service configurations can be published using
+the
+[services.configs.create](/service-management/reference/rest/v1/services.configs/create)
+or [services.configs.submit](/service-management/reference/rest/v1/services.configs/submit)
+methods.
+
+Alternatively, `services.configs.submit` allows publishing an
+[OpenAPI](https://github.com/OAI/OpenAPI-Specification) specification, formerly
+known as the Swagger Specification, which is automatically converted to a
+corresponding service configuration.
+
+## Service rollout
+
+REST URL: `https://servicemanagement.googleapis.com/v1/services/{service-name}/rollouts/{rollout-id}` <br />
+REST schema is defined [here](/service-management/reference/rest/v1/services.rollouts).
+
+A `Rollout` defines how Google Service Management should deploy service
+configurations to backend systems and how the configurations take effect at
+runtime. It lets service producers specify multiple service configuration
+versions to be deployed together, and a strategy that indicates how they
+should be used.
+
+Updating a managed service's configuration can be dangerous, as a configuration
+error can lead to a service outage. To mitigate risks, Service Management
+supports gradual rollout of service configuration changes. This feature gives
+service producers time to identity potential issues and rollback service
+configuration changes in case of errors, thus minimizing the customer
+impact of bad configurations. For example, you could specify that 5% of traffic
+uses configuration 1, while the remaining 95% uses configuration 2.
+
+Service Management keeps a history of rollouts so that service
+producers can undo to previous configuration versions. You can rollback a configuration
+by initiating a new `Rollout` that clones a previously submitted
+rollout record.

package/ondewo-csi-api/google/appengine/README.md

@@ -0,0 +1,12 @@
+# Google App Engine Admin API
+
+## Overview
+
+The Google App Engine Admin API is a RESTful API for managing App Engine
+applications. The Admin API provides programmatic access to several of the App
+Engine administrative operations that are found in the
+[Google Cloud Platform Console](https://cloud.google.com/appengine/docs/developers-console).
+
+## Documentation
+
+[Google App Engine Admin API Documentation](https://cloud.google.com/appengine/docs/admin-api/)

package/ondewo-csi-api/google/assistant/embedded/README.md

@@ -0,0 +1,3 @@
+The `Google Assistant API` allows developers to embed the Google Assistant into
+their devices. It provides an audio-in (spoken user query) and
+audio-out (Assistant spoken response).

package/ondewo-csi-api/google/cloud/functions/README.md

@@ -0,0 +1,2 @@
+API for managing lightweight user-provided functions executed in response to
+events.

package/ondewo-csi-api/google/cloud/runtimeconfig/README.md

@@ -0,0 +1,39 @@
+[TOC]
+
+# Introduction
+
+The RuntimeConfig service provides Google Cloud Platform users the ability to
+dynamically configure your service.
+
+The RuntimConfig service creates and manages RuntimeConfig resources
+within a Google Cloud Project and various variables within said resource.
+
+## Details
+
+Each cloud project can create multiple **Config** objects. A **Config** object
+by itself does not contain any configuration information, but rather is a
+logical grouping of variables. Variable names are hierarchical and follow file
+system style, where only leaf nodes can contain values.
+
+For example, you can have a configuration called *Flags*. Within that
+configuration object, you can create the following variables.
+
+* `/ports/service_port`
+* `/ports/monitoring_port`
+* `/ports/admin_port`
+
+This creates three variables: `/ports/serve_port`, `/ports/monitoring_port`,
+`/ports/admin_port`. Note that `/ports` cannot have a value but it can be
+listed.
+
+### Setup
+
+In order to make requests to RuntimeConfig service, you need to enable the API
+for your project.
+
+To achieve that, go to the
+[Google Cloud Console](https://console.cloud.google.com/apis/api/runtimeconfig.googleapis.com/overview)
+and enable *Google Cloud RuntimeConfig API* for your project.
+
+The documentation for this service is located
+[here](https://cloud.google.com/deployment-manager/runtime-configurator/reference/rest/).

package/ondewo-csi-api/google/cloud/speech/README.md

@@ -0,0 +1,3 @@
+# Introduction
+
+Google Cloud Speech API provides speech recognition as a service.

package/ondewo-csi-api/google/devtools/cloudbuild/README.md

@@ -0,0 +1 @@
+The Google Cloud Container Builder API lets you to build an application or part of an application from source code stored in Google Cloud Storage or a Google Cloud Source Repository and package it into container images. The container images are then stored in Google Container Registry. You can optionally copy the images to another container registry as required.

package/ondewo-csi-api/google/devtools/clouderrorreporting/README.md

@@ -0,0 +1 @@
+Read more about the Stackdriver Error Reporting API [here](https://cloud.google.com/error-reporting/reference/)

package/ondewo-csi-api/google/example/library/README.md

@@ -0,0 +1,4 @@
+# Introduction
+This is a Google example service representing a simple digital library.
+It manages a collection of shelf resources, and each shelf owns a collection
+of book resources.

package/ondewo-csi-api/google/genomics/README.md

@@ -0,0 +1,14 @@
+Stores, processes, explores and shares genomic data. This API implements
+the Global Alliance for Genomics and Health (GA4GH) v0.5.1 API as well as
+several extensions.
+
+The Google Genomics API supports access via both
+[JSON/REST](https://cloud.google.com/genomics/reference/rest) and
+[gRPC](https://cloud.google.com/genomics/reference/rpc). JSON/REST is more
+broadly available and is easier for getting started with Google Genomics; it
+works well for small metadata resources (datasets, variant sets, read group
+sets) and for browsing small genomic regions for datasets of any size. For
+performant bulk data access (reads and variants), use gRPC.
+
+See also an [overview of genomic resources](https://cloud.google.com/genomics/v1/users-guide)
+and an overview of [Genomics on Google Cloud](https://cloud.google.com/genomics/overview).

package/ondewo-csi-api/google/iam/README.md

@@ -0,0 +1,14 @@
+# Introduction
+
+# Key Concepts
+
+## Service Account
+
+A Service Account is an account used to identify services (non-humans) to Google.
+A Service Account has a list of Service Account Keys, which can be used to authenticate to Google.
+
+## Service Account Keys
+
+A Service Account Key is a public/private keypair generated by Google.  Google retains the public
+key, while the customer is given the private key.  The private key can be used to [sign JWTs and
+authenticate Service Accounts to Google](https://developers.google.com/identity/protocols/OAuth2ServiceAccount#authorizingrequests).

package/ondewo-csi-api/google/logging/README.md

@@ -0,0 +1,3 @@
+# Introduction
+
+The Stackdriver Logging service.

package/ondewo-csi-api/google/longrunning/README.md

@@ -0,0 +1,5 @@
+# Google Long Running Operations API
+
+This package contains the definition of an abstract interface that
+manages long running operations with API services.  See
+[google.longrunning.Operations][] for details.

package/ondewo-csi-api/google/privacy/dlp/README.md

@@ -0,0 +1,7 @@
+# Google Data Loss Prevention (DLP) API
+
+The Google Data Loss Prevention API provides methods for detection
+of privacy-sensitive fragments in text, images, and Google Cloud
+Platform storage repositories.
+
+Documentation: https://cloud.google.com/dlp/docs

package/ondewo-csi-api/google/pubsub/v1beta2/README.md

@@ -0,0 +1,136 @@
+## Overview
+This file describes an API for a Pub/Sub (Publish/Subscribe) system. This system
+provides a reliable many-to-many communication mechanism between independently
+written publishers and subscribers where the publisher publishes messages to
+*topics* and each subscriber creates a *subscription* and consumes *messages*
+from it.
+
+1.  The Pub/Sub system maintains bindings between topics and subscriptions.
+2.  A publisher publishes messages into a topic.
+3.  The Pub/Sub system delivers messages from topics into attached
+    subscriptions.
+4.  A subscriber receives pending messages from its subscription and
+    acknowledges each one to the Pub/Sub system.
+5.  The Pub/Sub system removes acknowledged messages from that subscription.
+
+## Data Model
+The data model consists of the following:
+
+*   **Topic**: A topic is a resource to which messages are published by
+    publishers. Topics are named, and the name of the topic is unique within the
+    Pub/Sub system.
+
+*   **Subscription**: A subscription records the subscriber's interest in a
+    topic. The Pub/Sub system maintains those messages which still need
+    to be delivered and acknowledged so that they can retried as needed.
+    The set of messages that have not been acknowledged is called the
+    subscription backlog.
+
+*   **Message**: A message is a unit of data that flows in the system. It
+    contains opaque data from the publisher along with its *attributes*.
+
+*   **Message Attributes** (optional): A set of opaque key-value pairs assigned
+    by the publisher to a message. Attributes are delivered unmodified to
+    subscribers together with the message data, if there's any.
+
+## Publisher Flow
+A publisher publishes messages to the topic using the `Publish` call:
+
+```data
+PubsubMessage message;
+message.set_data("....");
+message.attributes.put("key1", "value1");
+PublishRequest request;
+request.set_topic("topicName");
+request.add_message(message);
+Publisher.Publish(request);
+```
+
+## Subscriber Flow
+The subscriber part of the API is richer than the publisher part and has a
+number of concepts for subscription creation and use:
+
+1.  A subscriber (user or process) creates a subscription using the
+    `CreateSubscription` call.
+
+2.  A subscriber receives messages in one of two ways: via pull or push.
+
+  *   To receive messages via pull, a subscriber calls the `Pull` method on the
+      `Subscriber` to get messages from the subscription. For each individual
+      message, the subscriber may use the `ack_id` received in the
+      `PullResponse` to `Acknowledge` the message, or modify the *ack deadline*
+      with `ModifyAckDeadline`. See the `Subscription.ack_deadline_seconds`
+      field documentation for details on the ack deadline behavior. Messages
+      must be acknowledged or they will be redelivered in a future `Pull` call.
+
+      **Note:** Messages may be consumed in parallel by multiple processes
+      making `Pull` calls to the same subscription; this will result in the set
+      of messages from the subscription being split among the processes, each
+      process receiving a subset of the messages.
+
+  *   To receive messages via push, the `PushConfig` field must be specified in
+      the `Subscription` parameter when creating a subscription, or set with
+      `ModifyPushConfig`. The PushConfig specifies an endpoint at which the
+      subscriber exposes the `PushEndpointService` or some other handler,
+      depending on the endpoint. Messages are received via the
+      `ProcessPushMessage` method. The push subscriber responds to the method
+      with a result code that indicates one of three things: `Acknowledge` (the
+      message has been successfully processed and the Pub/Sub system may delete
+      it), `Nack` (the message has been rejected and the Pub/Sub system should
+      resend it at a later time).
+
+      **Note:** The endpoint may be a load balancer for better scalability, so
+      that multiple processes may handle the message processing load.
+
+Subscription creation:
+
+```data
+Subscription subscription;
+subscription.set_topic("topicName");
+subscription.set_name("subscriptionName");
+subscription.push_config().set_push_endpoint("machinename:8888");
+Subscriber.CreateSubscription(subscription);
+```
+
+Consuming messages via pull:
+
+```data
+// The subscription must be created without setting the push_config field.
+
+PullRequest pull_request;
+pull_request.set_subscription("subscriptionName");
+pull_request.set_return_immediately(false);
+pull_request.set_max_messages(10);
+while (true) {
+  PullResponse pull_response;
+  AcknowledgeRequest ack_request;
+  ackRequest.set_subscription("subscriptionName");
+  if (Subscriber.Pull(pull_request, pull_response) == OK) {
+    for (ReceivedMessage received in pull_response.received_messages()) {
+      Process(received.message().data());
+      ackRequest.add_ack_id(received.ack_id());
+    }
+  }
+  if (ackRequest.ack_ids().size() > 0) {
+    Subscriber.Acknowledge(ack_request);
+  }
+}
+```
+
+## Reliability Semantics
+When a subscriber successfully creates a subscription using
+`Subscriber.CreateSubscription`, it establishes a "subscription point" for
+that subscription, no later than the time that `Subscriber.CreateSubscription`
+returns. The subscriber is guaranteed to receive any message published after
+this subscription point. Note that messages published before the subscription
+point may or may not be delivered.
+
+Messages are not delivered in any particular order by the Pub/Sub system.
+Furthermore, the system guarantees *at-least-once* delivery of each message
+until acknowledged.
+
+## Deletion
+Both topics and subscriptions may be deleted.
+
+When a subscription is deleted, all messages are immediately dropped. If it
+is a pull subscriber, future pull requests will return NOT_FOUND.

package/ondewo-csi-api/google/rpc/README.md

@@ -0,0 +1,5 @@
+# Google RPC
+
+This package contains type definitions for general RPC systems. While
+[gRPC](https://github.com/grpc) is using these defintions, they
+are not designed specifically to support gRPC.

package/ondewo-csi-api/google/streetview/publish/README.md

@@ -0,0 +1 @@
+An API to contribute 360 photos to Google Street View. The API also allows the users to connect photos, update metadata of the photos, generate photo collections, and delete photos.

package/ondewo-csi-api/google/type/README.md

@@ -0,0 +1,16 @@
+# Google Common Types
+
+This package contains definitions of common types for Google APIs.
+All types defined in this package are suitable for different APIs to
+exchange data, and will never break binary compatibility. They should
+have design quality comparable to major programming languages like
+Java and C#.
+
+NOTE: Some common types are defined in the package `google.protobuf`
+as they are directly supported by Protocol Buffers compiler and
+runtime. Those types are called Well-Known Types.
+
+## Java Utilities
+
+A set of Java utilities for the Common Types are provided in the
+`//java/com/google/type/util/` package.