move gWhisper code to the open-source repository

.gitignore

@@ -0,0 +1,3 @@
+build/
+*.swp
+compile_commands.json

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "third_party/googletest"]
+	path = third_party/googletest
+	url = https://github.com/google/googletest.git

CMakeLists.txt

@@ -0,0 +1,55 @@
+# Copyright 2019 IBM Corporation
+# 
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+# 
+#     http://www.apache.org/licenses/LICENSE-2.0
+# 
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+cmake_minimum_required (VERSION 2.8)
+project (gWhisper)
+
+if(DEFINED CMAKE_BUILD_TYPE)
+else()
+    # By default we build in Debug mode. For releases,
+    # please run CMAKE with
+    # -DCMAKE_BUILD_TYPE=RelWithDebInfo
+
+    # non optimized with debug symbols:
+    set(CMAKE_BUILD_TYPE Debug)
+endif()
+
+if (CMAKE_VERSION VERSION_LESS "3.1")
+    if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
+        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
+    else()
+        set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
+    endif()
+else()
+    set(CMAKE_CXX_STANDARD 11)
+endif()
+
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+enable_testing()
+
+if(BUILD_CONFIG_USE_BOOST_REGEX)
+    add_definitions(-DBUILD_CONFIG_USE_BOOST_REGEX)
+endif()
+
+# this causes all built executables to be on build directory toplevel.
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR} )
+
+include_directories("${PROJECT_BINARY_DIR}")
+include_directories("${PROJECT_BINARY_DIR}/src")
+include_directories("${PROJECT_SOURCE_DIR}")
+include_directories("${PROJECT_SOURCE_DIR}/src")
+
+add_subdirectory(src)
+add_subdirectory(tests)
+add_subdirectory(third_party)

CONTRIBUTING.md

@@ -0,0 +1,151 @@
+# Contributing
+## Contributing In General
+Our project welcomes external contributions. If you have an itch, please feel
+free to scratch it.
+
+To contribute code or documentation, please submit a [pull request](https://github.com/ibm/gWhisper/pulls).
+
+A good way to familiarize yourself with the codebase and contribution process is
+to look for and tackle low-hanging fruit in the [issue tracker](https://github.com/ibm/gWhisper/issues).
+Before embarking on a more ambitious contribution, please quickly [get in touch](#communication) with us and have a look at the [PROJECT_SCOPE.md](PROJECT_SCOPE.md).
+
+**Note: We appreciate your effort, and want to avoid a situation where a contribution
+requires extensive rework (by you or by us), sits in backlog for a long time, or
+cannot be accepted at all!**
+
+### Proposing new features
+
+If you would like to implement a new feature, please [raise an issue](https://github.com/ibm/gWhisper/issues)
+before sending a pull request so the feature can be discussed. This is to avoid
+you wasting your valuable time working on a feature that the project developers
+are not interested in accepting into the code base.
+
+### Fixing bugs
+
+If you would like to fix a bug, please [raise an issue](https://github.com/ibm/gWhisper/issues) before sending a
+pull request so it can be tracked.
+
+### Merge approval
+
+The project maintainers use LGTM (Looks Good To Me) in comments on the code
+review to indicate acceptance. A change requires LGTMs from one of the
+maintainers of each component affected.
+
+For a list of the maintainers, see the [MAINTAINERS.md](MAINTAINERS.md) page.
+
+## Communication
+For feature requests, bug reports or technical discussions, please use the [issue tracker](https://github.com/ibm/gWhisper/issues).
+
+Depending on the need, we might create a channel on matrix.org (see [riot.im](https://about.riot.im/)) or on slack for general questions. In the meantime please contact one of the [maintainers](MAINTAINERS.md) directly for general questions or feedback.
+
+## Testing
+As we currently do not have a CI and test framework set up, but plan to do so in the future,
+we encourage contributors to ensure that existing unit-tests pass by running `make test` before
+submitting a pull request. Also it is highly appreciated if you implement unit-tests
+for new code.
+
+## Coding style guidelines
+Existing code might not always follow the guidelines listed below. However please
+write new code to correspond to these guidelines and feel free to re-factor old
+code to be compliant.
+
+### Directory structure
+We are trying to stay close to _Canonical Project Structure_ as described [in this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1204r0.html).
+All new code should follow the directory and naming conventions described here.
+
+### Indentation
+This project is indented using spaces. Tabs are not allowed. One level of indentation corresponds to 4 spaces.
+```
+void myMethod(bool f_condition)
+{
+    ...
+    if(f_condition)
+    {
+        if(otherCondition)
+        {
+            doSomething();
+        }
+    }
+}
+```
+
+### Naming conventions
+- Classes:
+    UpperCamelCase
+- Methods:
+    lowerCamelCase
+- Variables:
+    lowerCamelCase
+
+    Scope for variables is indicated by prefixes:
+```
+    g_      -> global scope
+    m_      -> object member variable
+    f_      -> variable given as method/function argument
+    f_out   -> variable given as method/function argument, out parameter.
+             I.e. caller expects function to write/modify data referenced
+             to by this variable.
+```
+
+### Scoping brackets
+The curly bracket at scope start and scope end should have the same indentation level and immediately be followed by a new-line:
+```
+if(condition)
+{
+    something();
+}
+```
+
+### Source code documentation
+For documenting code, please use the [doxygen style](http://www.doxygen.nl/manual/docblocks.html) method 3.
+For example to document a method:
+```
+/// Method for doing my stuff.
+/// This method is doing my stuff by doing ....
+myMethod()
+...
+```
+
+## Legal
+
+Each source file must include a license header for the Apache
+Software License 2.0:
+
+```
+Copyright [yyyy] [name of copyright owner]
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+```
+
+We have tried to make it as easy as possible to make contributions. This
+applies to how we handle the legal aspects of contribution. We use the
+same approach - the [Developer's Certificate of Origin 1.1 (DCO)](DCO1.1.txt) - that the Linux® Kernel [community](https://elinux.org/Developer_Certificate_Of_Origin)
+uses to manage code contributions.
+
+We simply ask that when submitting a patch for review, the developer
+must include a sign-off statement in the commit message.
+
+Here is an example Signed-off-by line, which indicates that the
+submitter accepts the DCO:
+
+```
+Signed-off-by: John Doe <[email protected]>
+```
+
+You can include this automatically when you commit a change to your
+local git repository using the following command:
+
+```
+git commit -s
+```
+

DCO1.1.txt

@@ -0,0 +1,25 @@
+Developer's Certificate of Origin 1.1
+
+       By making a contribution to this project, I certify that:
+
+       (a) The contribution was created in whole or in part by me and I
+           have the right to submit it under the open source license
+           indicated in the file; or
+
+       (b) The contribution is based upon previous work that, to the best
+           of my knowledge, is covered under an appropriate open source
+           license and I have the right under that license to submit that
+           work with modifications, whether created in whole or in part
+           by me, under the same open source license (unless I am
+           permitted to submit under a different license), as indicated
+           in the file; or
+
+       (c) The contribution was provided directly to me by some other
+           person who certified (a), (b) or (c) and I have not modified
+           it.
+
+       (d) I understand and agree that this project and the contribution
+           are public and that a record of the contribution (including all
+           personal information I submit with it, including my sign-off) is
+           maintained indefinitely and may be redistributed consistent with
+           this project or the open source license(s) involved.

MAINTAINERS.md

@@ -0,0 +1,6 @@
+# MAINTAINERS
+
+Rainer Schoenberger - [email protected]
+
+Eric Boehmler - [email protected]
+

PROJECT_SCOPE.md

@@ -0,0 +1,59 @@
+# Scope and design goals of the gWhisper CLI project
+This document defines the scope of gWhisper. It should be helpful to
+decide if a feature request or pull request will be accepted or not.
+
+However if you have ideas which do not quite fit the scope and you are willing to implement
+them, feel free to start a discussion.
+
+## User personas
+The scope of the project is probably defined best by looking at the intended users:
+
+### A gRPC service developer
+- Maybe uses gRPC for the first time
+- Wants to get to know gRPC by exploring a test server (hello world)
+- Wants to test and debug a gRPC service implementation
+
+### A gRPC API user
+- Maybe uses gRPC for the first time
+- Has to interface a badly documented service implementation
+- Wants to explore a gRPC service, as well as its exported RPCs and message types
+- Wants to execute RPCs to learn how the server reacts
+
+### A person giving technical support
+- Has deep knowledge of the service implementations
+- Wants to execute RPCs to recover a corrupted server state
+- Wants to execute RPCs to trigger actions which are not possible in static client implementations
+
+## What is important:
+- Tab completion
+    - Big plus in usability
+    - No need to look at documentation
+- Reflection support
+    - Discoverability: all provided services of the server are offered to the CLI user 
+    - User does not have to care about proto files at all. In fact he or she does
+      not even need to know what a proto file is :-)
+- Colors
+    - Modern terminals support color
+    - Complex data structures are much better to read with color highlighting
+- Documentation
+    - Users should not need to use internet search engines or write mails/issues to learn how to use the tool
+- The tool should be usable in a terminal
+    - All intended users are developers and assumed to be familiar with CLI tools
+    - A CLI tool tends to be more versatile and time-less than graphical interfaces
+    - Allows flexible use of the tool (e.g. via SSH, in scripts, etc.)
+
+## Nice to have, but not necessary:
+- Custom output formatting
+    - This tends to let gRPC be used as a production tool, which is not the primary goal of gWhisper
+- Syntax compatibility between releases
+    - This would allow use of the tool in long-living scripts or for _Machine to Machine_ communication production environments, which is not a goal of gWhisper.
+
+## What is not important:
+- Performance for executing gRPC calls
+    The tool is not intended to be used for executing large numbers of RPCs or
+    for transfering big chunks of data.
+- Output formatting in machine readable form (think JSON, XML, etc)
+    The tool is intended as a User Interface not for use in production environments.
+    If it is desired to process replies of a server with an algorithm, users
+    should directly implement their own gRPC client. (gRPC provides excellent
+    scripting interfaces)