@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" <jde...@vmware.com> 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" <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%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" <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%7Cudo%40vmware.com%7C7a18231640654f0546fc08d8f4651dc0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062421752074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BO8%2BENOPc05J%2BlA4Wu4O9kIyVetnK4xihMfEMaQ%2FbBs%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%7Cudo%40vmware.com%7C7a18231640654f0546fc08d8f4651dc0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062421752074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MhND%2BWSkG0BMe7wkoBm77n%2BzGavxMCIZ6nwRf6Vnyec%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%7Cudo%40vmware.com%7C7a18231640654f0546fc08d8f4651dc0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062421752074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iEtUrQhXVB3TK5esyN%2BMpxQpxQJMUyt3lOPFzywg%2Feg%3D&reserved=0>
to remove it and would like to get consensus to move forward with that effort.
