Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Dan Smith]

Some apache projects have a "sandbox" repo or module. - Eg 
https://github.com/apache/solr-sandbox orhttps://commons.apache.org/sandbox.html

-Dan



From: Charlie Black 
Sent: Monday, March 29, 2021 12:14 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

+ 1 to additional repos for extensions to Geode project to keep "extensions" or 
bolt-ons out of the Apache Geode.   I also have extensions that aren't 
committed to Geode.So definably a vibrant community surrounding Geode.

What todo with the code:  Just link to the branch/sha/fork/first addition to 
extensions/??? to the 2017 proposal.That would make finding the "source" 
and the design easier - 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FProtobuf%2BProtocol&data=04%7C01%7Cdasmith%40vmware.com%7C256303835d0f4565372408d8f2f541cf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526482478203218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aGmJQBPpeWpK5jbwS5wFF7OvqBLyEy4tbUELm0qRI7g%3D&reserved=0

Note:   Since this never got fully implemented - why is it in the implemented 
category.   Anyone with wiki access want to move it to "Unknown" since it is 
currently abandoned.

Charlie

On 3/29/21, 11:55 AM, "John Blum"  wrote:

How hard is it to put the work like Protobuf in a separate repository 
(attached to Geode in some way)? I am not sure what the (Apache) procedure is.

We need stop baking everything into the "core" of Apache Geode.  Most 
things that are non-essential (meaning, they are not required for Geode to 
carry out its primary responsibility as a data store, also & e.g. Redis 
Adapter) should be an "extension" (add-on), enabled with a plugin.

I fear this work would get lost if removed completely.  How would new (or 
even existing members) know where to find this work if interested? Branches are 
not a good alternative. A separate repo would make the entire process (e.g. 
releases) easier, not unlike the Kafka connector, or even Spring Data for that 
matter.

$0.02
-j


From: Bruce Schuchardt 
Sent: Monday, March 29, 2021 11:41 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

That's true John, but the Protobuf i/f is using the same code as the REST 
server to serialize/deserialize JSON documents.  It isn't any better at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON document 
handling is incomplete at best. It does not properly handle all forms of JSON 
or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

I worked on the protobuf client/server interface as long as anyone else 
but still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json 
documents and we never got beyond that as cache values with the protobuf i/f.  
People want to store data in Geode in a way that works with queries, delta 
propagation and other advanced features.  That was, and remains, the main 
problem for this interface.  Without that it's not even as good as the current 
REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it 
allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Cdasmith%40vmware.com%7C256303835d0f4565372408d8f2f541cf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526482478203218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4Vp59Fwl1fgQhLrUFVnZaClYIBA6RE5eIXD2A%2FRIZJM%3D&reserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all 
have multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, 
alt

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Charlie Black]

+ 1 to additional repos for extensions to Geode project to keep "extensions" or 
bolt-ons out of the Apache Geode.   I also have extensions that aren't 
committed to Geode.So definably a vibrant community surrounding Geode.

What todo with the code:  Just link to the branch/sha/fork/first addition to 
extensions/??? to the 2017 proposal.That would make finding the "source" 
and the design easier - 
https://cwiki.apache.org/confluence/display/GEODE/Protobuf+Protocol

Note:   Since this never got fully implemented - why is it in the implemented 
category.   Anyone with wiki access want to move it to "Unknown" since it is 
currently abandoned.

Charlie

On 3/29/21, 11:55 AM, "John Blum"  wrote:

How hard is it to put the work like Protobuf in a separate repository 
(attached to Geode in some way)? I am not sure what the (Apache) procedure is.

We need stop baking everything into the "core" of Apache Geode.  Most 
things that are non-essential (meaning, they are not required for Geode to 
carry out its primary responsibility as a data store, also & e.g. Redis 
Adapter) should be an "extension" (add-on), enabled with a plugin.

I fear this work would get lost if removed completely.  How would new (or 
even existing members) know where to find this work if interested? Branches are 
not a good alternative. A separate repo would make the entire process (e.g. 
releases) easier, not unlike the Kafka connector, or even Spring Data for that 
matter.

$0.02
-j


From: Bruce Schuchardt 
Sent: Monday, March 29, 2021 11:41 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

That's true John, but the Protobuf i/f is using the same code as the REST 
server to serialize/deserialize JSON documents.  It isn't any better at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON document 
handling is incomplete at best. It does not properly handle all forms of JSON 
or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

I worked on the protobuf client/server interface as long as anyone else 
but still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json 
documents and we never got beyond that as cache values with the protobuf i/f.  
People want to store data in Geode in a way that works with queries, delta 
propagation and other advanced features.  That was, and remains, the main 
problem for this interface.  Without that it's not even as good as the current 
REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it 
allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Ccblack%40vmware.com%7C646c03df5c2248faee2808d8f2e44538%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526409520158303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=35zrg%2BcXaxHTOgAgi9dfg0VFrkdna9ccbqazay4eZFM%3D&reserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all 
have multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, 
although not for as long as some of the other folks commenting. I'm ok with 
removing it. I do see some value in leaving stalled/incomplete projects around 
as bait for future developers to pick up - that seems to have worked for redis 
;) But if it is a maintenance burden lets drop it from develop. Someone can 
always pick it up from the history.

If I recall correctly, one of the big incomplete parts of the 
project is that we hadn't figured out how to serialize user objects efficiently 
with this protocol. The default was to convert PDX objects to JSON. That was 
about as efficient as the existing REST protocol, which also uses json.

-Dan
__

Fixed: apache/geode-native#3070 (master - d4ca2b9)

[Travis CI]

Build Update for apache/geode-native
-

Build: #3070
Status: Fixed

Duration: 1 hr, 17 mins, and 52 secs
Commit: d4ca2b9 (master)
Author: Dick Cavender
Message: Replacing master with contents of rel/v1.13.2

View the changeset: 
https://github.com/apache/geode-native/compare/fe66f52c700a...d4ca2b92287e

View the full build log and details: 
https://travis-ci.com/github/apache/geode-native/builds/221546423?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[John Blum]

How hard is it to put the work like Protobuf in a separate repository (attached 
to Geode in some way)? I am not sure what the (Apache) procedure is.

We need stop baking everything into the "core" of Apache Geode.  Most things 
that are non-essential (meaning, they are not required for Geode to carry out 
its primary responsibility as a data store, also & e.g. Redis Adapter) should 
be an "extension" (add-on), enabled with a plugin.

I fear this work would get lost if removed completely.  How would new (or even 
existing members) know where to find this work if interested? Branches are not 
a good alternative. A separate repo would make the entire process (e.g. 
releases) easier, not unlike the Kafka connector, or even Spring Data for that 
matter.

$0.02
-j


From: Bruce Schuchardt 
Sent: Monday, March 29, 2021 11:41 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

That's true John, but the Protobuf i/f is using the same code as the REST 
server to serialize/deserialize JSON documents.  It isn't any better at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON document 
handling is incomplete at best. It does not properly handle all forms of JSON 
or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

I worked on the protobuf client/server interface as long as anyone else but 
still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json 
documents and we never got beyond that as cache values with the protobuf i/f.  
People want to store data in Geode in a way that works with queries, delta 
propagation and other advanced features.  That was, and remains, the main 
problem for this interface.  Without that it's not even as good as the current 
REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it 
allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Cjblum%40vmware.com%7C194584c1dbf443f3dc2908d8f2e25613%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526401214937503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IpWa%2B8ys08lGLfBmboJXiVOZN3ZWQH%2FP4VXNa3r1kcY%3D&reserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all have 
multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, 
although not for as long as some of the other folks commenting. I'm ok with 
removing it. I do see some value in leaving stalled/incomplete projects around 
as bait for future developers to pick up - that seems to have worked for redis 
;) But if it is a maintenance burden lets drop it from develop. Someone can 
always pick it up from the history.

If I recall correctly, one of the big incomplete parts of the 
project is that we hadn't figured out how to serialize user objects efficiently 
with this protocol. The default was to convert PDX objects to JSON. That was 
about as efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

As the only remaining member on the CSharpDriver team, I too have 
an attachment to Protobuf. It’s purely technical, however, not emotional. I was 
truly excited about the prospects of a self-describing protocol and had hopes 
for a .NET client talking directly to geode without going through the C++ 
layer. The performance I measured doing puts/gets of a broad range of object 
sizes was at parity with the C++ client. I was truly surprised to see the 
project shelved. But I do understand we had extremely limited functionality not 
even close to an MVP. In hindsight, we should hav

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Bruce Schuchardt]

That's true John, but the Protobuf i/f is using the same code as the REST 
server to serialize/deserialize JSON documents.  It isn't any better at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON document 
handling is incomplete at best. It does not properly handle all forms of JSON 
or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

I worked on the protobuf client/server interface as long as anyone else but 
still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json 
documents and we never got beyond that as cache values with the protobuf i/f.  
People want to store data in Geode in a way that works with queries, delta 
propagation and other advanced features.  That was, and remains, the main 
problem for this interface.  Without that it's not even as good as the current 
REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it 
allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Cbruces%40vmware.com%7C5d8368fac65a41c6c4ba08d8f2d8b930%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526359926230999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vbqKr6CsdapWGW6p8ktTMW6VUuqxwkOEI2qxW84gbpo%3D&reserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all have 
multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, 
although not for as long as some of the other folks commenting. I'm ok with 
removing it. I do see some value in leaving stalled/incomplete projects around 
as bait for future developers to pick up - that seems to have worked for redis 
;) But if it is a maintenance burden lets drop it from develop. Someone can 
always pick it up from the history.

If I recall correctly, one of the big incomplete parts of the 
project is that we hadn't figured out how to serialize user objects efficiently 
with this protocol. The default was to convert PDX objects to JSON. That was 
about as efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

As the only remaining member on the CSharpDriver team, I too have 
an attachment to Protobuf. It’s purely technical, however, not emotional. I was 
truly excited about the prospects of a self-describing protocol and had hopes 
for a .NET client talking directly to geode without going through the C++ 
layer. The performance I measured doing puts/gets of a broad range of object 
sizes was at parity with the C++ client. I was truly surprised to see the 
project shelved. But I do understand we had extremely limited functionality not 
even close to an MVP. In hindsight, we should have put all the resources on the 
server side, as the client implementation was almost trivial.

Mike


---
Sent from Workspace ONE 
Boxer

On March 23, 2021 at 3:55:33 PM PDT, Udo Kohlmeyer 
 wrote:
Alexander, as you know, the intent for this work was to lower the 
barrier of entry, as the Geode wire protocol is not documented, which makes it 
impossible to contribute any clients in other languages to the project. The 
lack of documentation of this feature did also not help the case.

If no-one else sees

Passed: apache/geode-native#3067 (rel/v1.13.2 - 85b6261)

[Travis CI]

Build Update for apache/geode-native
-

Build: #3067
Status: Passed

Duration: 1 hr, 15 mins, and 9 secs
Commit: 85b6261 (rel/v1.13.2)
Author: Dick Cavender
Message: Bumping copyright year to 2021

View the changeset: https://github.com/apache/geode-native/compare/rel/v1.13.2

View the full build log and details: 
https://travis-ci.com/github/apache/geode-native/builds/221537521?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Charlie Black]

+1 to "removal of experimental Protobuf client/server interface"

If  someone offers to take on the completion of the  "experimental Protobuf 
client/server interface" in a timely manner,  then I would say hold off on 
removing.

As for the other removal items that were brought up.   Please raise those in a 
separate thread so we can get a proper vote on those items.

Other thoughts:   
* After its removal if someone does want to complete the "Protobuf 
client/server interface" they can revive the great work out that has already 
been done out of version control.
* A wish of completeness isn't really a statement of an intent to complete.   
* I am + 1 to the removal of work that is unfinished that hasn't seen progress 
in several years.This would make maintenance of Geode simpler.

Charlie 

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON document 
handling is incomplete at best. It does not properly handle all forms of JSON 
or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

I worked on the protobuf client/server interface as long as anyone else but 
still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json 
documents and we never got beyond that as cache values with the protobuf i/f.  
People want to store data in Geode in a way that works with queries, delta 
propagation and other advanced features.  That was, and remains, the main 
problem for this interface.  Without that it's not even as good as the current 
REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it 
allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Ccblack%40vmware.com%7C4a5f85320e78445c99db08d8f2d8b85d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526359908700570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jH7QFrF8YiIMAzywCprWBxF4Oh236gZ%2BNTISpER%2B4C0%3D&reserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all have 
multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, 
although not for as long as some of the other folks commenting. I'm ok with 
removing it. I do see some value in leaving stalled/incomplete projects around 
as bait for future developers to pick up - that seems to have worked for redis 
;) But if it is a maintenance burden lets drop it from develop. Someone can 
always pick it up from the history.

If I recall correctly, one of the big incomplete parts of the 
project is that we hadn't figured out how to serialize user objects efficiently 
with this protocol. The default was to convert PDX objects to JSON. That was 
about as efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

As the only remaining member on the CSharpDriver team, I too have 
an attachment to Protobuf. It’s purely technical, however, not emotional. I was 
truly excited about the prospects of a self-describing protocol and had hopes 
for a .NET client talking directly to geode without going through the C++ 
layer. The performance I measured doing puts/gets of a broad range of object 
sizes was at parity with the C++ client. I was truly surprised to see the 
project shelved. But I do understand we had extremely limited functionality not 
even close to an MVP. In hindsight, we should have put all the resources on the 
server side, as the client implementation was almost trivial.

Mike


---
Sent from Workspace ONE 
Boxer

Re: Very old geode-native PRs

[Mario Salazar de Torres]

Hi @Blake Bender,

Thanks for taking some time on clearing out old PRs. I'll progress #699, so it 
can be closed ASAP.

BR,
Mario.

From: Blake Bender 
Sent: Monday, March 29, 2021 8:24 PM
To: dev@geode.apache.org 
Subject: Very old geode-native PRs

Good morning!

We are attempting to push through all of the most longstanding geode-native 
PRs, so if you're involved in one as an author or a reviewer your prompt 
attention would be much appreciated.  There are 4 outstanding that I consider 
"very old," all initially submitted prior to the first of the year.  Here they 
are, with the latest statuses as I understand them.


  1.  PR 678, for GEODE-8601: https://github.com/apache/geode-native/pull/678.  
This one had an outstanding "change requested" review, which has kindly been 
removed this morning to unblock progress.  All CI checks are passing, so I will 
request a review internally today to see if there's anything that really must 
be done prior to merging.
  2.  PR 699 for GEODE-8698: https://github.com/apache/geode-native/pull/699.  
This has an outstanding "change requested" review, so I will contact the author 
of that today to follow up.  CI tasks are in a strange "pending" state, so it 
looks like this one was originally submitted prior to our making the CI public, 
and the new CI hasn't been run.  If the author would be kind enough to push an 
empty commit, that should probably force a run and we can see what state the 
code is in.  A rebase onto the latest develop branch is in order here, as well.
  3.  PR 705, for GEODE-8543: https://github.com/apache/geode-native/pull/705.  
Again the "change requested" review has been removed, and I will follow up with 
the team to get a new review ASAP.  This one is also in a stuck state with 
respect to CI, so again a rebase and push to clear things up would be 
appreciated.
  4.  PR 713, for GEODE-8442: https://github.com/apache/geode-native/pull/713.  
This one has had quite a bit of attention recently, and was rebased 10 days 
ago.  Review has been approved, and one integration test is failing in CI on 
all platforms.  Author has been notified.

Thanks,

Blake

Very old geode-native PRs

[Blake Bender]

Good morning!

We are attempting to push through all of the most longstanding geode-native 
PRs, so if you're involved in one as an author or a reviewer your prompt 
attention would be much appreciated.  There are 4 outstanding that I consider 
"very old," all initially submitted prior to the first of the year.  Here they 
are, with the latest statuses as I understand them.


  1.  PR 678, for GEODE-8601: https://github.com/apache/geode-native/pull/678.  
This one had an outstanding "change requested" review, which has kindly been 
removed this morning to unblock progress.  All CI checks are passing, so I will 
request a review internally today to see if there's anything that really must 
be done prior to merging.
  2.  PR 699 for GEODE-8698: https://github.com/apache/geode-native/pull/699.  
This has an outstanding "change requested" review, so I will contact the author 
of that today to follow up.  CI tasks are in a strange "pending" state, so it 
looks like this one was originally submitted prior to our making the CI public, 
and the new CI hasn't been run.  If the author would be kind enough to push an 
empty commit, that should probably force a run and we can see what state the 
code is in.  A rebase onto the latest develop branch is in order here, as well.
  3.  PR 705, for GEODE-8543: https://github.com/apache/geode-native/pull/705.  
Again the "change requested" review has been removed, and I will follow up with 
the team to get a new review ASAP.  This one is also in a stuck state with 
respect to CI, so again a rebase and push to clear things up would be 
appreciated.
  4.  PR 713, for GEODE-8442: https://github.com/apache/geode-native/pull/713.  
This one has had quite a bit of attention recently, and was rebased 10 days 
ago.  Review has been approved, and one integration test is failing in CI on 
all platforms.  Author has been notified.

Thanks,

Blake

Passed: apache/geode-examples#533 (rel/v1.13.2 - f52ac92)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #533
Status: Passed

Duration: 23 mins and 28 secs
Commit: f52ac92 (rel/v1.13.2)
Author: Dick Cavender
Message: Bumping version to 1.13.2

View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.13.2

View the full build log and details: 
https://travis-ci.com/github/apache/geode-examples/builds/221537507?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[John Blum]

Correction! Although a different/separate issue, Geode's JSON document handling 
is incomplete at best. It does not properly handle all forms of JSON or types 
(e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

I worked on the protobuf client/server interface as long as anyone else but 
still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json documents 
and we never got beyond that as cache values with the protobuf i/f.  People 
want to store data in Geode in a way that works with queries, delta propagation 
and other advanced features.  That was, and remains, the main problem for this 
interface.  Without that it's not even as good as the current REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it allowed 
for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-client&data=04%7C01%7Cjblum%40vmware.com%7C57064d5c95a942d5d45408d8ef9ef079%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522813216259200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B%2BH%2BrhN%2BfI1evkLtaONC%2FVliM7D7%2FUQbhLfFQ40yZBw%3D&reserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they all have 
multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, although 
not for as long as some of the other folks commenting. I'm ok with removing it. 
I do see some value in leaving stalled/incomplete projects around as bait for 
future developers to pick up - that seems to have worked for redis ;) But if it 
is a maintenance burden lets drop it from develop. Someone can always pick it 
up from the history.

If I recall correctly, one of the big incomplete parts of the project 
is that we hadn't figured out how to serialize user objects efficiently with 
this protocol. The default was to convert PDX objects to JSON. That was about 
as efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

As the only remaining member on the CSharpDriver team, I too have an 
attachment to Protobuf. It’s purely technical, however, not emotional. I was 
truly excited about the prospects of a self-describing protocol and had hopes 
for a .NET client talking directly to geode without going through the C++ 
layer. The performance I measured doing puts/gets of a broad range of object 
sizes was at parity with the C++ client. I was truly surprised to see the 
project shelved. But I do understand we had extremely limited functionality not 
even close to an MVP. In hindsight, we should have put all the resources on the 
server side, as the client implementation was almost trivial.

Mike


---
Sent from Workspace ONE 
Boxer

On March 23, 2021 at 3:55:33 PM PDT, Udo Kohlmeyer  
wrote:
Alexander, as you know, the intent for this work was to lower the 
barrier of entry, as the Geode wire protocol is not documented, which makes it 
impossible to contribute any clients in other languages to the project. The 
lack of documentation of this feature did also not help the case.

If no-one else sees ANY benefit of having a self-describing wire 
protocol as part of the project, then you should remove it. But as stated, 
without AND documentation pertaining to the wire protocol for Geode, removing 
the only self-describing protocol with serialization, adopted by many globally, 
will put the bar