Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialize project structure #8

Merged
merged 1 commit into from
Jun 4, 2020
Merged

Initialize project structure #8

merged 1 commit into from
Jun 4, 2020

Conversation

lherman-cs
Copy link
Contributor

@lherman-cs lherman-cs commented Jun 3, 2020

The main goal for the structure is to give easy access/navigation to KVS’s common use cases for customers, similar to how Chime does it for their JS SDK but for multiple libraries.

The structure is meant to be use case oriented. Each use case folder must have some descriptions about the use case. A use case folder might not contain sample codes, but only high level diagrams/explanations.

If a use case folder contains sample codes, the README should have the steps how to setup the project. The sample codes should not rely on other sample codes from other use cases. This also applies to the build systems. Consequently, each use case is self isolated.

By self isolating each use case, it'll reduce customer burden, customers should be able to use our samples to integrate our libraries easily to their projects and focus on a use case folder.

Format:

* README.md (list of KVS libraries and their use cases)
* <library 1>
    * <use case 1>
        * README.md (descriptions about the use case and how to setup/run or high level diagrams/concept)
    * <use case 2>
    * <use case n>
* <library 2>
* <library n>

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@lherman-cs lherman-cs marked this pull request as ready for review June 3, 2020 23:07
@disa6302
Copy link
Contributor

disa6302 commented Jun 3, 2020

Looks good. How do we plan on setting up the build system for this?
Since we are targeting demos from different assets.

@lherman-cs
Copy link
Contributor Author

I think we should have a minimal build system for each use case. It'll definitely put extra work on our side, but I think it has positive effect to the customers. They should be able to integrate our samples to their projects and navigate the samples easier.

@disa6302
Copy link
Contributor

disa6302 commented Jun 3, 2020

Agreed. We can have CMake files to pull in each SDK repo based on the samples we are running right? And then we would build the requisite dependencies by executing the make file, right? Is that your thought?

@lherman-cs
Copy link
Contributor Author

We can simply use either ExternalProject or FetchContent from Cmake.

Copy link
Contributor

@disa6302 disa6302 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Let us start with adding the existing samples in different SDKs to set precedent.

@lherman-cs lherman-cs merged commit 541c995 into master Jun 4, 2020
@lherman-cs lherman-cs deleted the init branch June 4, 2020 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants