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%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" <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%7Cjblum%40vmware.com%7C57064d5c95a942d5d45408d8ef9ef079%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522813216259200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bO4zkGtGKpzhmrKXwh11T%2F3C8YkZXFOh3OlDJeyyEsw%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%7Cjblum%40vmware.com%7C57064d5c95a942d5d45408d8ef9ef079%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522813216259200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zu%2BgFwmBUdh5q7poyyy7JpnWdK119XpoygnWlRbZ2sg%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%7Cjblum%40vmware.com%7C57064d5c95a942d5d45408d8ef9ef079%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522813216259200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KwYcBi0EQUcEDHg3exeJuBZ3FXXuLeQlXuKIP1qhHt4%3D&reserved=0>
to remove it and would like to get consensus to move forward with that effort.
