[
https://issues.apache.org/jira/browse/GEODE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628924#comment-14628924
]
John Blum commented on GEODE-125:
---------------------------------
Unfortunately https://github.com/gemfire is a "private" organization and so
{{py-gemfire-rest}} is not part of the public domain. This is something we
should perhaps review and publish as an OS "module" to _Apache Geode_, however.
> Provide additional native language client bindings to GemFire's REST API.
> -------------------------------------------------------------------------
>
> Key: GEODE-125
> URL: https://issues.apache.org/jira/browse/GEODE-125
> Project: Geode
> Issue Type: Improvement
> Components: client/server, general
> Affects Versions: 1.0.0-incubating
> Environment: Apache Geode + RESTful-based application clients in
> Geode's non-supported native languages.
> Reporter: John Blum
> Priority: Minor
> Labels: ApacheGeode, Bindings, NativeClient, REST_API
>
> This is an _Epic (story)_ to track the development of all applicable native
> REST client bindings implemented in different languages to allow those
> language-specific clients to interface with and use Apache Geode as the
> System of Record (SOR), Data Management Platform of choice.
> Some *examples+ of different supported client languages could include, but
> are not limited to:
> #. JavaScript
> #. PHP
> #. Python
> #. Ruby
> #. Scala
> This effort would fill the void created as result of GemFire's native client
> *drivers* (C#/C++) not being open sourced.
> The idea with the native client *bindings* would be to provide a native
> language look and feel to Geode's (GemFire's) API's. For instance...
> 1. The binding could provide a first-class facade and support around Geode's
> primary data operations (e.g. {{Region.get(key)}}, {{Region.put(key,
> value)}}), as well as...
> 2. Provide support for the conversion of native language client class types
> and object instance into and from JSON automatically. (Note, JSON is stored
> as a PDXInstance in Geode). In this way, the native client application can
> work in strongly-typed objects natural to the language.
> Keep in mind, that the performance characteristics as well as the UC's are
> different between native clients where a *driver* is available and where a
> *binding* could be provided.
> The *drivers* are optimized for low-latency and will have an immediate
> performance advantage over the *binding*.
> Still, there are things/features from the _driver_ the *binding* could
> implement, such as, but not limited to...
> 1. Single-Hop, direct data access to the Geode Server hosting the data (the
> "primary" in the PR case).
> 2. Load Balancing based on meta-data (JSON format) sent from a Locator.
> 3. Non-blocking, Reactive-style interface to Geode.
> 4. etc...
> The later is important motivation for having the *bindings* over the
> *drivers* since the prevailing requirement and UC in most applications today
> is "responsiveness", which is not necessarily just a factor of latency.
> There are many more ideas and things that could be explored here; please post
> in the comments to share your thoughts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
