I say delete it so you can move forward. If someone wants it in a subproject repo bad enough they can pull it from the previous commit. It is source control after all so it never really goes away.
-Jake > On Mar 30, 2021, at 8:01 AM, Bruce Schuchardt <bru...@vmware.com> 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" <jmelch...@vmware.com> 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" <jb...@vmware.com> 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 <bru...@vmware.com> > Sent: Monday, March 29, 2021 11:41 AM > To: dev@geode.apache.org <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" <jb...@vmware.com> 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 <bru...@vmware.com> > Sent: Thursday, March 25, 2021 8:01 AM > To: dev@geode.apache.org <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" <jde...@vmware.com> 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%7Cjabarrett%40vmware.com%7C5a30be69ad7b4e4ad15508d8f38cbef1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527133126944392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=p7%2B7YmMhoKk0Eovp7FuD0QLZMroHHVmyWBjzHYZastc%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" <dasm...@vmware.com> 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 <marte...@vmware.com> > Sent: Tuesday, March 23, 2021 4:53 PM > To: dev@geode.apache.org <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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cjabarrett%40vmware.com%7C5a30be69ad7b4e4ad15508d8f38cbef1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527133126944392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V0ABm6QP8kn9NVeUibWfn5mrGtjEYWIeL6uCaGuJ9C4%3D&reserved=0> > > On March 23, 2021 at 3:55:33 PM PDT, Udo Kohlmeyer > <u...@vmware.com> 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 barrier of entry of contributing to > Geode, outside of Java and C++/C# even higher. > > In addition, I'm sure that the contributors to the C++/C# > client could actually benefit in using this protocol. > > But I am just a single voice. > > --Udo > > On 3/24/21, 9:38 AM, "Alexander Murmann" > <amurm...@vmware.com> wrote: > > Udo, having worked on Protobuf with you, I share the > emotional attachment. I also agree that it's a valuable feature to have and > that ideally someone would pick it up. I don't think it's feature complete > enough at this point to be viable. Unlike with Redis, I haven't seen anyone > in the community contribute to it in a long time. If you or someone else were > to volunteer to do all the work you propose we do on Protobuf, I'd strongly > support keeping it. > > I think each of the other feature areas you propose as > potential removal candidates deserve their own dedicated discussion. I > understand some of them are harder to remove from a technical perspective or > neither experimental nor deprecated and would thus require a Geode 2.0. > ________________________________ > From: Udo Kohlmeyer <u...@vmware.com> > Sent: Tuesday, March 23, 2021 14:54 > To: dev@geode.apache.org <dev@geode.apache.org> > Subject: Re: [DISCUSS] removal of experimental > Protobuf client/server interface > > -1 > > Given that I was on the team that started this > initiative, I will naturally have an inclination to say 'No'. > > I don't know if I would go as far as removing this > project/initiative out of Geode. > I understand that the way that was used to hook into > Geode was less the perfect, and I fully support removing those and possibly > replacing them with viable alternatives, if that makes the core Geode project > better. What I don't support is the removal of the code completely on the > basis that it isn't used by anyone (we have no proof either direction). > > I think that the addition of this adapter is > beneficial to the Geode. Given that lack of documentation relating to the > Geode wire protocol, the barrier of entry for anyone else to connect to Geode > is HUGE. The Protobuf initiative was the effort to lower the bar of entry for > other > languages to be able to talk to Geode. But by removing > it, we make Geode less accessible. I think the lack of focus on this effort > can also attribute to the lack of use. As @Dave pointed out, there is little > to no documentation impact for the adapter. Which means, we (Geode) have > failed at marketing this feature. > > I propose that the Protobuf adapter NOT to be removed, > but rather reworked so that it fits more in line with our other extensions > like Redis and Memcache. Yes, we would have to maintain the code, but it is > not like we haven't been doing this with the Memcache or Redis extension for > a MUCH longer period than what we have for Protobuf. If we keep Protobuf, we > need promote it, so we should document this adapter. Alternatively, if we > remove Protobuf, we put effort into documented our wire protocol, so that > Geode wire protocol is not a closed box and a HUGE barrier for anyone wanting > to connect to Geode. > > If we vote to permanently remove the Protobuf from > Geode, I want to suggest that we put to vote the removal of many other > projects in Geode on the basis of lack of adoption: > * Geode-Rebalancer > * Geode-Memcache > * Geode-Connector > * Geode-Redis > * Geode Offheap > > These are projects that we maintain without any > (known) users actively using these features. > > --Udo > > On 3/24/21, 2:16 AM, "Bruce Schuchardt" > <bru...@vmware.com> wrote: > > Hi folks, > > We’ve had an experimental client/server interface > in Geode that no-one to my knowledge is using. We’re testing it with every > build and are having to make changes to it to keep it up to date with the > rest of the project. The last change of substance to the geode-protobuf > sub-project, for instance, was in 2018 but that’s been followed by many > incidental commits. > > > GEM-8997<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8997&data=04%7C01%7Cjabarrett%40vmware.com%7C5a30be69ad7b4e4ad15508d8f38cbef1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527133126944392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Cn4UDC9Ee8UGAEgI95nGznM%2Fs3J0eYgjuvWCp3lXYMw%3D&reserved=0> > was opened to have the sub-projects for this interface removed. I’ve > prepared a pull > request<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6168&data=04%7C01%7Cjabarrett%40vmware.com%7C5a30be69ad7b4e4ad15508d8f38cbef1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527133126944392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PIWRb7XzSjCQh95I3ly8BGED6kwcM0qikiBVJ1bWNEQ%3D&reserved=0> > to remove it and would like to get consensus to move forward with that > effort. > > > > > > >
