geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hitesh Khamesra <hitesh...@yahoo.com.INVALID>
Subject Re: Simple Java Client
Date Mon, 24 Apr 2017 23:10:09 GMT
I would imagine rest client for mobile device..



      From: Michael Stolz <mstolz@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 <klund@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 <fkrone@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
> >
>


   
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message