Re: Simple Java Client

t;> sbawas...@pivotal.io> > > >>>>>>> > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> I had looked at the JCache in the past and here are some of the > > >>&g

Re: Simple Java Client

t;>>>>> > >>>>>>>> I > >>>>>>>> > >>>>>>>>> noted: > >>>>>>>>>> > >>>>>>>>>> Naming convention: Geode's region is a Cache in JSR-107, and >

Re: Simple Java Client

>>>>>>>>>> >>>>>>>>> the >>>>> >>>>>> meaning >>>>>>>>> >>>>>>>>>> of cache. Also, how do you document this given that Cache means >>>>>>>>>>

Re: Simple Java Client

;>> >>>>>>>> Given >>>> >>>>> this, >>>>>>> >>>>>>>> users will not be able to switch from an existing >>>>>>>>> >>>>>>>> implementation >>> >>>> to >>>> >>>>> ours; &

Re: Simple Java Client

;>> CacheLoader, CacheListener etc. will need handle on jsr-107 > >>>>> “cache”. > >>>>>>>>> JSR-107 supports features like an EntryProcessor, which is a > >>>>> function > >>>>>>>>> invoked at

Re: Simple Java Client

gt;>> On Tue, Apr 25, 2017 at 2:55 PM Dan Smith <dsm...@pivotal.io> >>>>> wrote: >>>>>>>>>> What transport are you planning on using? REST, or the >>> current >>>>>> binary >>>>>>>>>> protocol? Or is this just a wrapper around the existing java

Re: Simple Java Client

signatures are essentially a (non spring) caching standard for Java developers at this point. We considered full blown JSR 107 implementation but thought it was too robust for the needs mentioned (that's not to say we couldn't get there incrementally). I think those needs still

Re: Simple Java Client

> > > > > we > > > > > > > > support (REST, binary, ...) and the client drivers that use > > those > > > > > > > protocols > > > > > > > > should just be ways of accessing that API. The Java API on > th

Re: Simple Java Client

at we support on the server. The > > > > protocols > > > > > > we > > > > > > > > support (REST, binary, ...) and the client drivers that use > > those > > > > > > > protocols > > > > > > > >

Re: Simple Java Client

> > > > > > gfsh and things you can do with the current client that have no > > > java > > > > > API > > > > > > > equivalent. I think we really need to fix that! > > > > > > > > > > > > > > Als

Re: Simple Java Client

gt; > level > > > > > > API that automatically exposed all new features that would make > > > adding > > > > > new > > > > > > features much less painful. > > > > > > > > > > > > I do like the idea of adding a reactive API. > >

Re: Simple Java Client

r around the current API without too much work. I don't > > > think > > > > we > > > > > should do anything for JSR-107 other than provide a JSR-107 > > compatible > > > > > wrapper - if someone wants additional geode specific

Re: Simple Java Client

in our existing client > > > just > > > > by refactoring the code a bit more and shinking geode-core into a > bare > > > > minimum. > > > > > > > > -Dan > > > > > > > > On Mon, Apr 24, 2017 at 8:20 PM, Fred Krone <fkr.

Re: Simple Java Client

gt; -Dan > > > > > > > > On Mon, Apr 24, 2017 at 8:20 PM, Fred Krone <fkr...@pivotal.io> > wrote: > > > > > > > > > That's great, Wes. I will take a look. Thanks. > > > > > > > > > > John -- good feedbac

Re: Simple Java Client

"In my mind, there really are only 2 approaches... *Spring* and > > > > non-*Spring*, > > > > or rather PCF and non-PCF, and since PCF is primarily based on Boot > > > (given > > > > Microservices/applications are the new concurrency), then I

Re: Simple Java Client

gt; > > > "In my mind, there really are only 2 approaches... *Spring* and > > > > non-*Spring*, > > > > or rather PCF and non-PCF, and since PCF is primarily based on Boot > > > (given > > > > Microservices/applications are the new co

Re: Simple Java Client

tempt to give the community > > something > > > that had the same standardized experience as JSR 107 -- starting with > the > > > Cache interface itself. Although we don't necessarily have to > implement > > > Cache, it's method signatures are essentially

Re: Simple Java Client

attempt to give the community > > something > > > that had the same standardized experience as JSR 107 -- starting with > the > > > Cache interface itself. Although we don't necessarily have to > implement > > > Cache, it's method signatures are essentially a (non spring) caching > > > standa

Re: Simple Java Client

this point. We considered full blown > JSR > > 107 implementation but thought it was too robust for the needs mentioned > > (that's not to say we couldn't get there incrementally). I think those > > needs still exist open-source outside of PCF and don't cannibalize. > > > > > > > &

Re: Simple Java Client

y have to implement > > Cache, it's method signatures are essentially a (non spring) caching > > standard for Java developers at this point. We considered full blown > JSR > > 107 implementation but thought it was too robust for the needs mentioned > > (that's not to say w

Re: Simple Java Client

t; On Mon, Apr 24, 2017 at 7:44 PM, Real Wes <thereal...@outlook.com> wrote: > > > > > Here is a simple Java client _for enterprise use_ that I developed for > > Geode and distributed to several enterprises. It has similarities and > > differences for your goal. This proj

Re: Simple Java Client

; > > > On Mon, Apr 24, 2017 at 7:44 PM, Real Wes <thereal...@outlook.com> wrote: > > > > > Here is a simple Java client _for enterprise use_ that I developed for > > Geode and distributed to several enterprises. It has similarities and > > differences for y

Re: Simple Java Client

till exist open-source outside of PCF and don't cannibalize. On Mon, Apr 24, 2017 at 7:44 PM, Real Wes <thereal...@outlook.com> wrote: > > Here is a simple Java client _for enterprise use_ that I developed for > Geode and distributed to several enterprises. It has simil

Re: Simple Java Client

Here is a simple Java client _for enterprise use_ that I developed for Geode and distributed to several enterprises. It has similarities and differences for your goal. This project creates both server and client regions dynamically. It lists regions, alters regions… really anything that GFSH

Re: Simple Java Client

The ability to dynamically, yet intelligently create Regions on the client as well as the server is being handle in SDG^2 right now, under the new Annotation configuration model (inspired by *Spring Boot*, *auto-configuration,* work I did in *Spring Session *and *SD Cassandra,* and tidbits I came

Re: Simple Java Client

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 wrote: > Perhaps I'm picking nits, but I think a

Re: Simple Java Client

> On Apr 24, 2017, at 3:03 PM, Fred Krone wrote: > > Calls are asynchronous -- futures I’m reading this as “Reactive API [1]” Anthony [1] http://www.reactive-streams.org

Re: Simple Java Client

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

Re: Simple Java Client

+1 for calling it a driver :) On 4/24/17 16:07, Michael William Dodge 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

Re: Simple Java Client

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

Re: Simple Java Client

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

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 wrote: > A couple things I'd like to see: > > 1)

Re: Simple Java Client

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

Re: Simple Java Client

I would suggest working closely with John Blum on this as I believe he already provides similar functionality in Spring Data Geode. Also, would this be the beginning of a client-side admin API with the intention of fleshing that out completely in the future? --Jens On Mon, Apr 24, 2017 at 3:03

Simple Java Client

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