Re: [DISCUSS] removal of experimental Protobuf client/server interface
I'd volunteer to do that. If it gets deleted and then 'revived' under another repo, does that still require it to be an Apache project? What are the requirements? --Jens On 3/30/21, 8:02 AM, "Bruce Schuchardt" wrote: Does anyone want to take on the work of moving these sub-projects to another repository? I picked up the ticket because it's costing us development and testing time but am not interested in being the owner of it in some other repo. On 3/30/21, 5:45 AM, "Joris Melchior" wrote: +1 On this approach. If we could somehow have side project to implement this I think it would be really helpful. I also think it's less intimidating to contribute to for a lot of people. Joris On 2021-03-29, 2:55 PM, "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%7Cjdeppe%40vmware.com%7C01ffb8cfb18849bc16eb08d8f38cd318%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527133457524428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m3o05hvXMcD9icL%2F4SmxPT2amv0cqP%2BIEn6U%2Fz3ZMy8%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 incomple
Re: [DISCUSS] removal of experimental Protobuf client/server interface
Hi Jens, With respect to the work we did with geode-kafka-connector, we did the initial development in a private branch. (gradle dependencies on geode, separate from Geode source code) Later when we were feature complete and ready for Confluence Certification, we created a new apache repo in geode org and published it there. We are also doing the partition region clear work in a feature branch, which will be merged to develop, when it is feature complete, fully vetted, and tested. I would say, if this protobuf code will be merged into develop when it is ready, feature-complete, and tested. We can do the dev work as a branch in apache/geode.git repo, with periodic rebasing on develop. Regards, Nabarun From: Jens Deppe Sent: Wednesday, March 31, 2021 9:50 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface I'd volunteer to do that. If it gets deleted and then 'revived' under another repo, does that still require it to be an Apache project? What are the requirements? --Jens On 3/30/21, 8:02 AM, "Bruce Schuchardt" wrote: Does anyone want to take on the work of moving these sub-projects to another repository? I picked up the ticket because it's costing us development and testing time but am not interested in being the owner of it in some other repo. On 3/30/21, 5:45 AM, "Joris Melchior" wrote: +1 On this approach. If we could somehow have side project to implement this I think it would be really helpful. I also think it's less intimidating to contribute to for a lot of people. Joris On 2021-03-29, 2:55 PM, "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%7Cnnag%40vmware.com%7Cf65716b19378402f4ed408d8f4651f1a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062452588820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iXjw3gFEBG1VMIKDLjG%2BJpJFUwI4xwpJT6BLPQNSPtc%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
Re: [DISCUSS] removal of experimental Protobuf client/server interface
@Jens, I'll be willing to help you if you need some help. I find it extremely sad that we would lose this work, as I believe we really taking as step backwards by just blindly removing this work (even if not feature complete). --Udo On 4/1/21, 3:50 AM, "Jens Deppe" wrote: I'd volunteer to do that. If it gets deleted and then 'revived' under another repo, does that still require it to be an Apache project? What are the requirements? --Jens On 3/30/21, 8:02 AM, "Bruce Schuchardt" wrote: Does anyone want to take on the work of moving these sub-projects to another repository? I picked up the ticket because it's costing us development and testing time but am not interested in being the owner of it in some other repo. On 3/30/21, 5:45 AM, "Joris Melchior" wrote: +1 On this approach. If we could somehow have side project to implement this I think it would be really helpful. I also think it's less intimidating to contribute to for a lot of people. Joris On 2021-03-29, 2:55 PM, "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%7Cudo%40vmware.com%7C7a18231640654f0546fc08d8f4651dc0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062421752074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AfXhqtTw3qZKtBysL55ZIjItu%2B3VL00tqzcdY2hpe4c%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, alth
