You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2017/01/16 16:26:31 UTC
Native Client Directory Structure
One of the first things necessary to get NC merged into the the develop
branch is understanding where it will go under the current geode project
structure.
The quick and obvious solution is adding a 'geode-nativeclient` subproject
and relocating all the NC sources into that directory.
Given that NC consists of two semi-distinct clients, C++ and .NET, it may
also make sense to organize more of a hierarchy. Consider:
geode-client/
geode++
geode.net
(or some other more creative names)
Keep in mind that today the .NET client is very tightly coupled with the
C++ client, so you can't build .NET without first building C++.
My suggestion would be to do the quick and easy now and as we continue to
refine and refactor and hopefully write the .NET in pure CLI we make that
move them. Perhaps by that time there will be a pure Java client to include
in that structure.
Thoughts?
-Jake
Re: Native Client Directory Structure
Posted by Michael Martell <mm...@pivotal.io>.
I was initially confused by using the term Native Client for our .NET and
C++ clients. If I'm a newcomer to GemFire, is it not more confusing to use
the term Native? I vote for switching our terminology to just GemFire +
Clients, where the clients can currently be written in Java, .NET, or C++.
When our pure .NET implementation comes out (i.e., all CSharp, no C++/CLI
wrapper and no C++), it should be a full replacement for our existing .NET
client.
On Mon, Jan 16, 2017 at 8:55 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> .NET libraries can be written in any language that supports compilation to
> CLI. This includes C++/CLI, C#, F#, etc. [1]. Your project need not be
> written in the same language as the library. This is why I would suggest we
> not name the client library after the language we used to write it.
>
> [1] https://en.wikipedia.org/wiki/List_of_CLI_languages
>
> On Mon, Jan 16, 2017 at 8:50 AM Michael William Dodge <md...@pivotal.io>
> wrote:
>
> > I'm not an expert at .NET development so please bear with me. In that
> > world, is CLI synonymous with C#? It seems that people who want a
> non-Java
> > client for Geode would be thinking of it in terms of programming
> language,
> > which is why I suggested csharp. It seems like people writing Geode
> clients
> > currently have three options for programming language: Java, C++, and C#.
> >
> > Sarge
> >
> > > On 16 Jan, 2017, at 08:45, Jacob Barrett <jb...@pivotal.io> wrote:
> > >
> > > On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge <
> mdodge@pivotal.io
> > >
> > > wrote:
> > >
> > >> Given that the current source structure uses cpp and cli prefixes for
> > the
> > >> C++ and .NET clients, respectively, what about using cpp and cli for
> the
> > >> directories, allowing any new .NET development to go into a separate
> > >> directory (perhaps cs or csharp) without any additional moves?
> > >>
> > >
> > > Sarge,
> > >
> > > Given that .NET/CLI is language independent, calling a forthcoming pure
> > CLI
> > > client after it's potential language would not be appropriate.
> > >
> > > If the concerns is more moves than leaving everything under a
> > > "geode-native" directory might make most sense. Later we could add
> > > "geode-cli" when the new pure CLI client is developed. Then slowly
> phase
> > > out the CLI inside the "geode-native".
> > >
> > > -Jake
> >
> >
>
Re: Native Client Directory Structure
Posted by Jacob Barrett <jb...@pivotal.io>.
.NET libraries can be written in any language that supports compilation to
CLI. This includes C++/CLI, C#, F#, etc. [1]. Your project need not be
written in the same language as the library. This is why I would suggest we
not name the client library after the language we used to write it.
[1] https://en.wikipedia.org/wiki/List_of_CLI_languages
On Mon, Jan 16, 2017 at 8:50 AM Michael William Dodge <md...@pivotal.io>
wrote:
> I'm not an expert at .NET development so please bear with me. In that
> world, is CLI synonymous with C#? It seems that people who want a non-Java
> client for Geode would be thinking of it in terms of programming language,
> which is why I suggested csharp. It seems like people writing Geode clients
> currently have three options for programming language: Java, C++, and C#.
>
> Sarge
>
> > On 16 Jan, 2017, at 08:45, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge <mdodge@pivotal.io
> >
> > wrote:
> >
> >> Given that the current source structure uses cpp and cli prefixes for
> the
> >> C++ and .NET clients, respectively, what about using cpp and cli for the
> >> directories, allowing any new .NET development to go into a separate
> >> directory (perhaps cs or csharp) without any additional moves?
> >>
> >
> > Sarge,
> >
> > Given that .NET/CLI is language independent, calling a forthcoming pure
> CLI
> > client after it's potential language would not be appropriate.
> >
> > If the concerns is more moves than leaving everything under a
> > "geode-native" directory might make most sense. Later we could add
> > "geode-cli" when the new pure CLI client is developed. Then slowly phase
> > out the CLI inside the "geode-native".
> >
> > -Jake
>
>
Re: Native Client Directory Structure
Posted by Michael William Dodge <md...@pivotal.io>.
I'm not an expert at .NET development so please bear with me. In that world, is CLI synonymous with C#? It seems that people who want a non-Java client for Geode would be thinking of it in terms of programming language, which is why I suggested csharp. It seems like people writing Geode clients currently have three options for programming language: Java, C++, and C#.
Sarge
> On 16 Jan, 2017, at 08:45, Jacob Barrett <jb...@pivotal.io> wrote:
>
> On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge <md...@pivotal.io>
> wrote:
>
>> Given that the current source structure uses cpp and cli prefixes for the
>> C++ and .NET clients, respectively, what about using cpp and cli for the
>> directories, allowing any new .NET development to go into a separate
>> directory (perhaps cs or csharp) without any additional moves?
>>
>
> Sarge,
>
> Given that .NET/CLI is language independent, calling a forthcoming pure CLI
> client after it's potential language would not be appropriate.
>
> If the concerns is more moves than leaving everything under a
> "geode-native" directory might make most sense. Later we could add
> "geode-cli" when the new pure CLI client is developed. Then slowly phase
> out the CLI inside the "geode-native".
>
> -Jake
Re: Native Client Directory Structure
Posted by Jacob Barrett <jb...@pivotal.io>.
Udo,
Not sure what part of my email you are +1ing.
-Jake
On Mon, Jan 16, 2017 at 8:45 AM Jacob Barrett <jb...@pivotal.io> wrote:
> On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge <md...@pivotal.io>
> wrote:
>
> Given that the current source structure uses cpp and cli prefixes for the
> C++ and .NET clients, respectively, what about using cpp and cli for the
> directories, allowing any new .NET development to go into a separate
> directory (perhaps cs or csharp) without any additional moves?
>
>
> Sarge,
>
> Given that .NET/CLI is language independent, calling a forthcoming pure
> CLI client after it's potential language would not be appropriate.
>
> If the concerns is more moves than leaving everything under a
> "geode-native" directory might make most sense. Later we could add
> "geode-cli" when the new pure CLI client is developed. Then slowly phase
> out the CLI inside the "geode-native".
>
> -Jake
>
>
>
Re: Native Client Directory Structure
Posted by Jacob Barrett <jb...@pivotal.io>.
On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge <md...@pivotal.io>
wrote:
> Given that the current source structure uses cpp and cli prefixes for the
> C++ and .NET clients, respectively, what about using cpp and cli for the
> directories, allowing any new .NET development to go into a separate
> directory (perhaps cs or csharp) without any additional moves?
>
Sarge,
Given that .NET/CLI is language independent, calling a forthcoming pure CLI
client after it's potential language would not be appropriate.
If the concerns is more moves than leaving everything under a
"geode-native" directory might make most sense. Later we could add
"geode-cli" when the new pure CLI client is developed. Then slowly phase
out the CLI inside the "geode-native".
-Jake
Re: Native Client Directory Structure
Posted by Michael William Dodge <md...@pivotal.io>.
Given that the current source structure uses cpp and cli prefixes for the C++ and .NET clients, respectively, what about using cpp and cli for the directories, allowing any new .NET development to go into a separate directory (perhaps cs or csharp) without any additional moves?
Sarge
> On 16 Jan, 2017, at 08:26, Jacob Barrett <jb...@pivotal.io> wrote:
>
> One of the first things necessary to get NC merged into the the develop
> branch is understanding where it will go under the current geode project
> structure.
>
> The quick and obvious solution is adding a 'geode-nativeclient` subproject
> and relocating all the NC sources into that directory.
>
> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
> also make sense to organize more of a hierarchy. Consider:
> geode-client/
> geode++
> geode.net
> (or some other more creative names)
> Keep in mind that today the .NET client is very tightly coupled with the
> C++ client, so you can't build .NET without first building C++.
>
> My suggestion would be to do the quick and easy now and as we continue to
> refine and refactor and hopefully write the .NET in pure CLI we make that
> move them. Perhaps by that time there will be a pure Java client to include
> in that structure.
>
> Thoughts?
>
>
> -Jake
Re: Native Client Directory Structure
Posted by Anilkumar Gingade <ag...@pivotal.io>.
+1 Separate repo for clients...Jake has valid point...
-Anil.
On Mon, Jan 16, 2017 at 12:07 PM, Michael William Dodge <md...@pivotal.io>
wrote:
> +1 for at least a separate repo for the clients. Jake makes a good point
> about dependencies on different toolchains. I'm not sure whether that would
> merit have a separate repo for each platform's client, e.g., a repo for the
> Java client, a repo for the C# client, etc. My instinct is to divide the
> software along lines that matches how people who want to develop against
> the client APIs think of things. For example, Netty is for Java, dotNetty
> is for C#, and nettyplusplus is for C++. Would the developers of Geode
> clients think more in terms of a client API implemented for different
> platforms or different platforms that have a client API?
>
> Sarge
>
> > On 16 Jan, 2017, at 11:56, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > +1 for separate repo for sub-projects that would or could likely release
> > independently of the core project. I see this applying to most clients,
> > .net, c++, python, etc. It also cleanly separates out the build process
> > which is quite different between these projects. The native clients in
> > particular are dependent a on bunch of toolchains that aren't part of the
> > standard core developer's toolbox. Even if released together under the
> > umbrella of the Geode product it may still make sense to let them evolve
> > independently in their own repos to isolate the concerns between the
> > sources.
> >
> >
> >
> > On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io>
> wrote:
> >
> >> I’m cautiously in favor of this idea. Allowing independent parts
> (geode,
> >> geode-examples, geode-native) to progress and release at their own pace
> >> seems like a good thing.
> >>
> >> From a release perspective, I think each repo would have separate vote
> >> threads and a section on our release page:
> >> http://geode.apache.org/releases/
> >>
> >> Anthony
> >>
> >>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> >>>
> >>> I would love a separate repo. Someone told me that wasn't an option. If
> >>> it's an option the let's make it so.
> >>>
> >>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
> >>>
> >>>> Jake,
> >>>>
> >>>> Having all the clients in the repository is nice, however, has there
> >> been
> >>>> thought to have them in their own repository? Now that we are a TLP,
> we
> >> do
> >>>> have that capability, as seen with the 'geode-examples' repository.
> >>>>
> >>>> --Mark
> >>>>
> >>>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <
> ukohlmeyer@pivotal.io>
> >>>> wrote:
> >>
> >>
>
>
Re: Native Client Directory Structure
Posted by Michael William Dodge <md...@pivotal.io>.
+1 for at least a separate repo for the clients. Jake makes a good point about dependencies on different toolchains. I'm not sure whether that would merit have a separate repo for each platform's client, e.g., a repo for the Java client, a repo for the C# client, etc. My instinct is to divide the software along lines that matches how people who want to develop against the client APIs think of things. For example, Netty is for Java, dotNetty is for C#, and nettyplusplus is for C++. Would the developers of Geode clients think more in terms of a client API implemented for different platforms or different platforms that have a client API?
Sarge
> On 16 Jan, 2017, at 11:56, Jacob Barrett <jb...@pivotal.io> wrote:
>
> +1 for separate repo for sub-projects that would or could likely release
> independently of the core project. I see this applying to most clients,
> .net, c++, python, etc. It also cleanly separates out the build process
> which is quite different between these projects. The native clients in
> particular are dependent a on bunch of toolchains that aren't part of the
> standard core developer's toolbox. Even if released together under the
> umbrella of the Geode product it may still make sense to let them evolve
> independently in their own repos to isolate the concerns between the
> sources.
>
>
>
> On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io> wrote:
>
>> I’m cautiously in favor of this idea. Allowing independent parts (geode,
>> geode-examples, geode-native) to progress and release at their own pace
>> seems like a good thing.
>>
>> From a release perspective, I think each repo would have separate vote
>> threads and a section on our release page:
>> http://geode.apache.org/releases/
>>
>> Anthony
>>
>>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> I would love a separate repo. Someone told me that wasn't an option. If
>>> it's an option the let's make it so.
>>>
>>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
>>>
>>>> Jake,
>>>>
>>>> Having all the clients in the repository is nice, however, has there
>> been
>>>> thought to have them in their own repository? Now that we are a TLP, we
>> do
>>>> have that capability, as seen with the 'geode-examples' repository.
>>>>
>>>> --Mark
>>>>
>>>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
>>>> wrote:
>>
>>
Re: Native Client Directory Structure
Posted by Michael Stolz <ms...@pivotal.io>.
+1 for a separate repo per client.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Mon, Jan 16, 2017 at 4:02 PM, Swapnil Bawaskar <sb...@pivotal.io>
wrote:
> +1 for a separate repo for each client.
>
> On Mon, Jan 16, 2017 at 12:25 PM, Joey McAllister <jm...@pivotal.io>
> wrote:
>
> > +1 to the separate repo.
> >
> > I think it also makes sense—especially with independent release
> > schedules—to keep the client documentation source in the client repo and
> > build it as its own User Guide, which we can host in its own section on
> > geode.apache.org/docs/.
> >
> > On Mon, Jan 16, 2017 at 12:14 PM Udo Kohlmeyer <uk...@pivotal.io>
> > wrote:
> >
> > +1 to separate client repos. Or at least some ability to independently
> > version client code for releases.
> >
> > --Udo
> >
> >
> > On 1/16/17 11:56, Jacob Barrett wrote:
> > > +1 for separate repo for sub-projects that would or could likely
> release
> > > independently of the core project. I see this applying to most clients,
> > > .net, c++, python, etc. It also cleanly separates out the build process
> > > which is quite different between these projects. The native clients in
> > > particular are dependent a on bunch of toolchains that aren't part of
> the
> > > standard core developer's toolbox. Even if released together under the
> > > umbrella of the Geode product it may still make sense to let them
> evolve
> > > independently in their own repos to isolate the concerns between the
> > > sources.
> > >
> > >
> > >
> > > On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io>
> > wrote:
> > >
> > >> I’m cautiously in favor of this idea. Allowing independent parts
> > (geode,
> > >> geode-examples, geode-native) to progress and release at their own
> pace
> > >> seems like a good thing.
> > >>
> > >> From a release perspective, I think each repo would have separate
> vote
> > >> threads and a section on our release page:
> > >> http://geode.apache.org/releases/
> > >>
> > >> Anthony
> > >>
> > >>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >>>
> > >>> I would love a separate repo. Someone told me that wasn't an option.
> If
> > >>> it's an option the let's make it so.
> > >>>
> > >>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org>
> wrote:
> > >>>
> > >>>> Jake,
> > >>>>
> > >>>> Having all the clients in the repository is nice, however, has there
> > >> been
> > >>>> thought to have them in their own repository? Now that we are a TLP,
> > we
> > >> do
> > >>>> have that capability, as seen with the 'geode-examples' repository.
> > >>>>
> > >>>> --Mark
> > >>>>
> > >>>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <
> > ukohlmeyer@pivotal.io>
> > >>>> wrote:
> > >>
> >
>
Re: Native Client Directory Structure
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
+1 for a separate repo for each client.
On Mon, Jan 16, 2017 at 12:25 PM, Joey McAllister <jm...@pivotal.io>
wrote:
> +1 to the separate repo.
>
> I think it also makes sense—especially with independent release
> schedules—to keep the client documentation source in the client repo and
> build it as its own User Guide, which we can host in its own section on
> geode.apache.org/docs/.
>
> On Mon, Jan 16, 2017 at 12:14 PM Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
>
> +1 to separate client repos. Or at least some ability to independently
> version client code for releases.
>
> --Udo
>
>
> On 1/16/17 11:56, Jacob Barrett wrote:
> > +1 for separate repo for sub-projects that would or could likely release
> > independently of the core project. I see this applying to most clients,
> > .net, c++, python, etc. It also cleanly separates out the build process
> > which is quite different between these projects. The native clients in
> > particular are dependent a on bunch of toolchains that aren't part of the
> > standard core developer's toolbox. Even if released together under the
> > umbrella of the Geode product it may still make sense to let them evolve
> > independently in their own repos to isolate the concerns between the
> > sources.
> >
> >
> >
> > On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io>
> wrote:
> >
> >> I’m cautiously in favor of this idea. Allowing independent parts
> (geode,
> >> geode-examples, geode-native) to progress and release at their own pace
> >> seems like a good thing.
> >>
> >> From a release perspective, I think each repo would have separate vote
> >> threads and a section on our release page:
> >> http://geode.apache.org/releases/
> >>
> >> Anthony
> >>
> >>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> >>>
> >>> I would love a separate repo. Someone told me that wasn't an option. If
> >>> it's an option the let's make it so.
> >>>
> >>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
> >>>
> >>>> Jake,
> >>>>
> >>>> Having all the clients in the repository is nice, however, has there
> >> been
> >>>> thought to have them in their own repository? Now that we are a TLP,
> we
> >> do
> >>>> have that capability, as seen with the 'geode-examples' repository.
> >>>>
> >>>> --Mark
> >>>>
> >>>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <
> ukohlmeyer@pivotal.io>
> >>>> wrote:
> >>
>
Re: Native Client Directory Structure
Posted by Joey McAllister <jm...@pivotal.io>.
+1 to the separate repo.
I think it also makes sense—especially with independent release
schedules—to keep the client documentation source in the client repo and
build it as its own User Guide, which we can host in its own section on
geode.apache.org/docs/.
On Mon, Jan 16, 2017 at 12:14 PM Udo Kohlmeyer <uk...@pivotal.io>
wrote:
+1 to separate client repos. Or at least some ability to independently
version client code for releases.
--Udo
On 1/16/17 11:56, Jacob Barrett wrote:
> +1 for separate repo for sub-projects that would or could likely release
> independently of the core project. I see this applying to most clients,
> .net, c++, python, etc. It also cleanly separates out the build process
> which is quite different between these projects. The native clients in
> particular are dependent a on bunch of toolchains that aren't part of the
> standard core developer's toolbox. Even if released together under the
> umbrella of the Geode product it may still make sense to let them evolve
> independently in their own repos to isolate the concerns between the
> sources.
>
>
>
> On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io> wrote:
>
>> I’m cautiously in favor of this idea. Allowing independent parts (geode,
>> geode-examples, geode-native) to progress and release at their own pace
>> seems like a good thing.
>>
>> From a release perspective, I think each repo would have separate vote
>> threads and a section on our release page:
>> http://geode.apache.org/releases/
>>
>> Anthony
>>
>>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> I would love a separate repo. Someone told me that wasn't an option. If
>>> it's an option the let's make it so.
>>>
>>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
>>>
>>>> Jake,
>>>>
>>>> Having all the clients in the repository is nice, however, has there
>> been
>>>> thought to have them in their own repository? Now that we are a TLP, we
>> do
>>>> have that capability, as seen with the 'geode-examples' repository.
>>>>
>>>> --Mark
>>>>
>>>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
>>>> wrote:
>>
Re: Native Client Directory Structure
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
+1 to separate client repos. Or at least some ability to independently
version client code for releases.
--Udo
On 1/16/17 11:56, Jacob Barrett wrote:
> +1 for separate repo for sub-projects that would or could likely release
> independently of the core project. I see this applying to most clients,
> .net, c++, python, etc. It also cleanly separates out the build process
> which is quite different between these projects. The native clients in
> particular are dependent a on bunch of toolchains that aren't part of the
> standard core developer's toolbox. Even if released together under the
> umbrella of the Geode product it may still make sense to let them evolve
> independently in their own repos to isolate the concerns between the
> sources.
>
>
>
> On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io> wrote:
>
>> I\u2019m cautiously in favor of this idea. Allowing independent parts (geode,
>> geode-examples, geode-native) to progress and release at their own pace
>> seems like a good thing.
>>
>> From a release perspective, I think each repo would have separate vote
>> threads and a section on our release page:
>> http://geode.apache.org/releases/
>>
>> Anthony
>>
>>> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> I would love a separate repo. Someone told me that wasn't an option. If
>>> it's an option the let's make it so.
>>>
>>> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
>>>
>>>> Jake,
>>>>
>>>> Having all the clients in the repository is nice, however, has there
>> been
>>>> thought to have them in their own repository? Now that we are a TLP, we
>> do
>>>> have that capability, as seen with the 'geode-examples' repository.
>>>>
>>>> --Mark
>>>>
>>>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
>>>> wrote:
>>
Re: Native Client Directory Structure
Posted by Jacob Barrett <jb...@pivotal.io>.
+1 for separate repo for sub-projects that would or could likely release
independently of the core project. I see this applying to most clients,
.net, c++, python, etc. It also cleanly separates out the build process
which is quite different between these projects. The native clients in
particular are dependent a on bunch of toolchains that aren't part of the
standard core developer's toolbox. Even if released together under the
umbrella of the Geode product it may still make sense to let them evolve
independently in their own repos to isolate the concerns between the
sources.
On Mon, Jan 16, 2017 at 11:52 AM Anthony Baker <ab...@pivotal.io> wrote:
> I’m cautiously in favor of this idea. Allowing independent parts (geode,
> geode-examples, geode-native) to progress and release at their own pace
> seems like a good thing.
>
> From a release perspective, I think each repo would have separate vote
> threads and a section on our release page:
> http://geode.apache.org/releases/
>
> Anthony
>
> > On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > I would love a separate repo. Someone told me that wasn't an option. If
> > it's an option the let's make it so.
> >
> > On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
> >
> >> Jake,
> >>
> >> Having all the clients in the repository is nice, however, has there
> been
> >> thought to have them in their own repository? Now that we are a TLP, we
> do
> >> have that capability, as seen with the 'geode-examples' repository.
> >>
> >> --Mark
> >>
> >> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
> >> wrote:
>
>
Re: Native Client Directory Structure
Posted by Anthony Baker <ab...@pivotal.io>.
I’m cautiously in favor of this idea. Allowing independent parts (geode, geode-examples, geode-native) to progress and release at their own pace seems like a good thing.
From a release perspective, I think each repo would have separate vote threads and a section on our release page: http://geode.apache.org/releases/
Anthony
> On Jan 16, 2017, at 11:24 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I would love a separate repo. Someone told me that wasn't an option. If
> it's an option the let's make it so.
>
> On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
>
>> Jake,
>>
>> Having all the clients in the repository is nice, however, has there been
>> thought to have them in their own repository? Now that we are a TLP, we do
>> have that capability, as seen with the 'geode-examples' repository.
>>
>> --Mark
>>
>> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
>> wrote:
Re: Native Client Directory Structure
Posted by Jacob Barrett <jb...@pivotal.io>.
I would love a separate repo. Someone told me that wasn't an option. If
it's an option the let's make it so.
On Mon, Jan 16, 2017 at 11:20 AM Mark Bretl <mb...@apache.org> wrote:
> Jake,
>
> Having all the clients in the repository is nice, however, has there been
> thought to have them in their own repository? Now that we are a TLP, we do
> have that capability, as seen with the 'geode-examples' repository.
>
> --Mark
>
> On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
>
> > -1 "geode-native" directory name
> >
> > +1 "geode-client" directory name
> >
> > Maybe the directories for the different clients are by language, so we
> > omit the "geode" prefix i.e
> >
> > geode-client/
> > c++,
> > net
> > java
> > python
> > ....
> >
> > If clients are in their own project, then the clients can be
> independently
> > versioned of the server code. imo, there should be no need for them to be
> > in lock-stead with the server code.
> >
> > --Udo
> >
> >
> >
> > On 1/16/17 08:52, Jacob Barrett wrote:
> >
> >> Let's try this again. Using the +1 mechanism for a multipart email is
> >> tough
> >> so please include a comment on which part you are +1ing.
> >>
> >> Also, I want to revise my suggestion to just call the directory
> >> 'geode-native' rather than 'geode-nativeclient'. Simply because I am
> lazy
> >> and don't want to type the extra 6 letters all the time.
> >>
> >> -Jake
> >>
> >> On Mon, Jan 16, 2017 at 8:26 AM Jacob Barrett <jb...@pivotal.io>
> >> wrote:
> >>
> >> One of the first things necessary to get NC merged into the the develop
> >>> branch is understanding where it will go under the current geode
> project
> >>> structure.
> >>>
> >>> The quick and obvious solution is adding a 'geode-nativeclient`
> >>> subproject
> >>> and relocating all the NC sources into that directory.
> >>>
> >>> Given that NC consists of two semi-distinct clients, C++ and .NET, it
> may
> >>> also make sense to organize more of a hierarchy. Consider:
> >>> geode-client/
> >>> geode++
> >>> geode.net
> >>> (or some other more creative names)
> >>> Keep in mind that today the .NET client is very tightly coupled with
> the
> >>> C++ client, so you can't build .NET without first building C++.
> >>>
> >>> My suggestion would be to do the quick and easy now and as we continue
> to
> >>> refine and refactor and hopefully write the .NET in pure CLI we make
> that
> >>> move them. Perhaps by that time there will be a pure Java client to
> >>> include
> >>> in that structure.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>> -Jake
> >>>
> >>>
> >>>
> >
>
Re: Native Client Directory Structure
Posted by Mark Bretl <mb...@apache.org>.
Jake,
Having all the clients in the repository is nice, however, has there been
thought to have them in their own repository? Now that we are a TLP, we do
have that capability, as seen with the 'geode-examples' repository.
--Mark
On Mon, Jan 16, 2017 at 10:38 AM, Udo Kohlmeyer <uk...@pivotal.io>
wrote:
> -1 "geode-native" directory name
>
> +1 "geode-client" directory name
>
> Maybe the directories for the different clients are by language, so we
> omit the "geode" prefix i.e
>
> geode-client/
> c++,
> net
> java
> python
> ....
>
> If clients are in their own project, then the clients can be independently
> versioned of the server code. imo, there should be no need for them to be
> in lock-stead with the server code.
>
> --Udo
>
>
>
> On 1/16/17 08:52, Jacob Barrett wrote:
>
>> Let's try this again. Using the +1 mechanism for a multipart email is
>> tough
>> so please include a comment on which part you are +1ing.
>>
>> Also, I want to revise my suggestion to just call the directory
>> 'geode-native' rather than 'geode-nativeclient'. Simply because I am lazy
>> and don't want to type the extra 6 letters all the time.
>>
>> -Jake
>>
>> On Mon, Jan 16, 2017 at 8:26 AM Jacob Barrett <jb...@pivotal.io>
>> wrote:
>>
>> One of the first things necessary to get NC merged into the the develop
>>> branch is understanding where it will go under the current geode project
>>> structure.
>>>
>>> The quick and obvious solution is adding a 'geode-nativeclient`
>>> subproject
>>> and relocating all the NC sources into that directory.
>>>
>>> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
>>> also make sense to organize more of a hierarchy. Consider:
>>> geode-client/
>>> geode++
>>> geode.net
>>> (or some other more creative names)
>>> Keep in mind that today the .NET client is very tightly coupled with the
>>> C++ client, so you can't build .NET without first building C++.
>>>
>>> My suggestion would be to do the quick and easy now and as we continue to
>>> refine and refactor and hopefully write the .NET in pure CLI we make that
>>> move them. Perhaps by that time there will be a pure Java client to
>>> include
>>> in that structure.
>>>
>>> Thoughts?
>>>
>>>
>>> -Jake
>>>
>>>
>>>
>
Re: Native Client Directory Structure
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
-1 "geode-native" directory name
+1 "geode-client" directory name
Maybe the directories for the different clients are by language, so we
omit the "geode" prefix i.e
geode-client/
c++,
net
java
python
....
If clients are in their own project, then the clients can be
independently versioned of the server code. imo, there should be no need
for them to be in lock-stead with the server code.
--Udo
On 1/16/17 08:52, Jacob Barrett wrote:
> Let's try this again. Using the +1 mechanism for a multipart email is tough
> so please include a comment on which part you are +1ing.
>
> Also, I want to revise my suggestion to just call the directory
> 'geode-native' rather than 'geode-nativeclient'. Simply because I am lazy
> and don't want to type the extra 6 letters all the time.
>
> -Jake
>
> On Mon, Jan 16, 2017 at 8:26 AM Jacob Barrett <jb...@pivotal.io> wrote:
>
>> One of the first things necessary to get NC merged into the the develop
>> branch is understanding where it will go under the current geode project
>> structure.
>>
>> The quick and obvious solution is adding a 'geode-nativeclient` subproject
>> and relocating all the NC sources into that directory.
>>
>> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
>> also make sense to organize more of a hierarchy. Consider:
>> geode-client/
>> geode++
>> geode.net
>> (or some other more creative names)
>> Keep in mind that today the .NET client is very tightly coupled with the
>> C++ client, so you can't build .NET without first building C++.
>>
>> My suggestion would be to do the quick and easy now and as we continue to
>> refine and refactor and hopefully write the .NET in pure CLI we make that
>> move them. Perhaps by that time there will be a pure Java client to include
>> in that structure.
>>
>> Thoughts?
>>
>>
>> -Jake
>>
>>
Re: Native Client Directory Structure
Posted by Jacob Barrett <jb...@pivotal.io>.
Let's try this again. Using the +1 mechanism for a multipart email is tough
so please include a comment on which part you are +1ing.
Also, I want to revise my suggestion to just call the directory
'geode-native' rather than 'geode-nativeclient'. Simply because I am lazy
and don't want to type the extra 6 letters all the time.
-Jake
On Mon, Jan 16, 2017 at 8:26 AM Jacob Barrett <jb...@pivotal.io> wrote:
> One of the first things necessary to get NC merged into the the develop
> branch is understanding where it will go under the current geode project
> structure.
>
> The quick and obvious solution is adding a 'geode-nativeclient` subproject
> and relocating all the NC sources into that directory.
>
> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
> also make sense to organize more of a hierarchy. Consider:
> geode-client/
> geode++
> geode.net
> (or some other more creative names)
> Keep in mind that today the .NET client is very tightly coupled with the
> C++ client, so you can't build .NET without first building C++.
>
> My suggestion would be to do the quick and easy now and as we continue to
> refine and refactor and hopefully write the .NET in pure CLI we make that
> move them. Perhaps by that time there will be a pure Java client to include
> in that structure.
>
> Thoughts?
>
>
> -Jake
>
>
Re: Native Client Directory Structure
Posted by Michael Stolz <ms...@pivotal.io>.
+1 Makes sense to me
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Mon, Jan 16, 2017 at 11:26 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> One of the first things necessary to get NC merged into the the develop
> branch is understanding where it will go under the current geode project
> structure.
>
> The quick and obvious solution is adding a 'geode-nativeclient` subproject
> and relocating all the NC sources into that directory.
>
> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
> also make sense to organize more of a hierarchy. Consider:
> geode-client/
> geode++
> geode.net
> (or some other more creative names)
> Keep in mind that today the .NET client is very tightly coupled with the
> C++ client, so you can't build .NET without first building C++.
>
> My suggestion would be to do the quick and easy now and as we continue to
> refine and refactor and hopefully write the .NET in pure CLI we make that
> move them. Perhaps by that time there will be a pure Java client to include
> in that structure.
>
> Thoughts?
>
>
> -Jake
>
Re: Native Client Directory Structure
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
+1
There are discussions relating to the pure Java client. I think it would
fight right into the "geode-client" project.
--Udo
On 1/16/17 08:26, Jacob Barrett wrote:
> One of the first things necessary to get NC merged into the the develop
> branch is understanding where it will go under the current geode project
> structure.
>
> The quick and obvious solution is adding a 'geode-nativeclient` subproject
> and relocating all the NC sources into that directory.
>
> Given that NC consists of two semi-distinct clients, C++ and .NET, it may
> also make sense to organize more of a hierarchy. Consider:
> geode-client/
> geode++
> geode.net
> (or some other more creative names)
> Keep in mind that today the .NET client is very tightly coupled with the
> C++ client, so you can't build .NET without first building C++.
>
> My suggestion would be to do the quick and easy now and as we continue to
> refine and refactor and hopefully write the .NET in pure CLI we make that
> move them. Perhaps by that time there will be a pure Java client to include
> in that structure.
>
> Thoughts?
>
>
> -Jake
>