"Also, would this be the beginning of a client-side admin API with the
intention of fleshing that out completely in the future?"
I think that is a long term idea and we'd want to keep that in-mind... but
short term it's the ability to provide some lightweight basic admin
functionality (create / update / destroy a region) to any node or
application wanting to become a client (do distributed caching) with geode
server / cluster.
On Mon, Apr 24, 2017 at 4:10 PM, Hitesh Khamesra <
hitesh...@yahoo.com.invalid> wrote:
> I would imagine rest client for mobile device..
>
>
>
> From: Michael Stolz <mst...@pivotal.io>
> To: dev@geode.apache.org
> Sent: Monday, April 24, 2017 3:55 PM
> Subject: Re: Simple Java Client
>
> +1 I'd really like this to be a thin client. Something that would fit
> comfortably on a mobile device.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Mon, Apr 24, 2017 at 6:51 PM, Kirk Lund <kl...@apache.org> wrote:
>
> > A couple things I'd like to see:
> >
> > 1) completely new API that doesn't reuse the old API classes (or at least
> > not the giant classes such as Cache and Region interfaces)
> > 2) separation of API and Impl so that users can compile their code
> against
> > a dedicated client API jar
> >
> > On Mon, Apr 24, 2017 at 3:03 PM, 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
> > >
> >
>
>
>
>
