We used to always say "client library" but somehow people started dropping
"library".
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771
On Mon, Apr 24, 2017 at 7:07 PM, Michael William Dodge <mdo...@pivotal.io>
wrote:
> Perhaps I'm picking nits, but I think a library that provides an API for
> interacting with Geode isn't a client. (I like to call it a driver.) The
> client is the application that someone write to use that API to interact
> with Geode. I recognize that in the past the C++ library for Geode has been
> called the "native client" but to me the term "client" implies a
> stand-alone application that has user functionality built into it.
>
> Sarge
>
> > On 24 Apr, 2017, at 15:03, Fred Krone <fkr...@pivotal.io> wrote:
> >
> > In an effort to improve Java developer ease of use for caching with
> Geode I
> > am looking for feedback on going forward with creating a Java client.
> This
> > client will allow for server-side region creation and distributed data
> > caching. This would allow for a thin client that fits with microservice
> > caching patterns and also abstracts a cleaner client-server experience
> > driven interface.
> >
> > Initially we were going to update the Region interface but were concerned
> > with breaking existing applications. We also would like to provide
> Region
> > creation to a client application and so propose here solving both of
> these
> > areas with a Java client.
> >
> > It would have new project repo for the client.
> >
> > It would provide new Region interface for clients. The specifics of the
> > API design are too lengthy for this conversation but implementation will
> > resemble JSR 107 Cache interface.
> >
> > It would use the new security framework.
> >
> >
> > *An example*,
> >
> > The client application simply creates an instance of client and points it
> > to the locator:
> >
> >
> > org.apache.geode.client.Client client = Client.create(locatorHost,
> > locatorPort);
> >
> >
> > Client has the following methods:
> >
> > package org.apache.geode.client;
> >
> >
> > public interface GeodeClient {
> >
> > /**
> >
> > * creates the region on the servers, or gets the region if it exits,
> > returns a PROXY region
> >
> > */
> >
> > public Region getOrCreateRegion(RegionAttributes attributes, String
> name);
> >
> >
> > /**
> >
> > * Returns a PROXY region if the region exists on the server
> >
> > */
> >
> > public Region getRegion(String name);
> >
> >
> >
> >
> >
> >
> > MVP
> >
> > The smallest set of features to test this idea, learn and iterate, and
> get
> > the client into the communities hands for future iterations is:
> >
> >
> > Create a server side Region from a client
> >
> > Region interface has CRUD on par with javax.cache.Cache (from JSR 107)
> >
> > Calls are asynchronous -- futures
> >
> >
> >
> > Also would like feedback on which future functionality would be most
> useful
> > from a thin client:
> >
> > Function execution
> >
> > Durable clients
> >
> > User defined serialization
> >
> > Register interest
> >
> > Queries
> >
> > CQ
> >
> > Near side caching
> >
> > Create disk stores from client
> >
> > Region group membership
> >
> > Client subscription load balancing
> > Transactions
> >
> >
> > Thanks,
> > -Fred
>
>
