geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Baker (JIRA)" <>
Subject [jira] [Commented] (GEODE-125) Provide additional native language client bindings to GemFire's REST API.
Date Wed, 15 Jul 2015 23:39:04 GMT


Anthony Baker commented on GEODE-125:

Yes, it would be interesting to see if it makes sense to move that work under the Geode project.
 It is already available as open source under an ASL 2.0 license.

> Provide additional native language client bindings to GemFire's REST API.
> -------------------------------------------------------------------------
>                 Key: GEODE-125
>                 URL:
>             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
> #. 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

View raw message