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 > >