Re: Simple Java Client

The point to supporting standards is that if we have standard compliant apis we can also plug into other libraries without custom effort. Yes some effort is needed on the admin side but such is true for all the systems that implement JSR-107. The goal was to make the usage, not the administration,

Re: Simple Java Client

We could have a simple wrapper around geode API for JSR-107, but I still don't see how this is helpful. I can read a book about JSR-107 and try to use geode, but then I wanted to create a PartitionedRegion in Geode, the book didn't tell me anything about that (since it is implementation specific),

Re: Simple Java Client

"geode-client-api.jar" (not ai) On Thu, Apr 27, 2017 at 2:20 PM, Kirk Lund wrote: > Different module or different repo is same thing I'm suggesting. Make it > separate and independent such that a Client can be compiled only with > geode-client-ai.jar. > > On Wed, Apr 26, 2017 at 4:52 PM, Bruce S

Re: Simple Java Client

Different module or different repo is same thing I'm suggesting. Make it separate and independent such that a Client can be compiled only with geode-client-ai.jar. On Wed, Apr 26, 2017 at 4:52 PM, Bruce Schuchardt wrote: > I don't think we should mix the old client code with a new API. We shoul

Re: Simple Java Client

A little late to the party...a great thread for discussing options and there is nothing 'simple' about it ;) I agree with Jake to follow closer to industry protocols and standards rather than creating our own. If we want to grow and sustain the Geode community, adding 'features' which integrate wi

Re: Simple Java Client

I like the idea of a separate code base (including repo) for separate problem domains. I think trying to fit a new API inside or parallel to the existing API has too high of a likelihood of confusion. Sarge > On 26 Apr, 2017, at 16:52, Bruce Schuchardt wrote: > > I don't think we should mix t

Re: Simple Java Client

I don't think we should mix the old client code with a new API. We should keep the new client code separate from the server. Maybe even in a different repo, as I think Fred suggested. Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit : If we want to add a new API then I suggest we create new API pac

Re: Simple Java Client

If we want to add a new API then I suggest we create new API packages and leave the "cache" package as the old deprecated API for backwards compatibility. The new APIs and implementation could be separated into different geode modules and packages (something like what follows): org.apache.geode.a

Re: Simple Java Client

The conservation on this thread is getting more focused on adopting JCache (JSR107) standard... Fred started this conversation to see if some of the admin APIs can be supported as part of Java API, to help devs who wants to combine both admin and business logic in the same application... Currentl

Re: Simple Java Client

This is an awesome discussion and Jake's hitting all the right notes about why JCache is a good idea! I've fought that fight in the past and lost it but I'm happy to see it coming back... What's really nice about Geode is that the functionalities and capabilities are all there, they're just not th

Re: Simple Java Client

Wes, Those are almost all administrative commands and have no place on the client API. They belong on an administrative API or as I'm arguing a series of MBeans/JMX as it is already an established standard. -Jake On Wed, Apr 26, 2017 at 8:09 AM Wes Williams wrote: > Now we're getting some prec

Re: Simple Java Client

Now we're getting some precision. Let's talk about the "raw" Geode proprietary bad ass API! Would that "raw" Geode proprietary bad ass API "raw" Geode proprietary bad ass API that we're talking about be centered around the commands found here: https://github.com/apache/geode/tree/rel/v1.1.1/geode

Re: Simple Java Client

Java and its community have standards for all of these issue so why re-invent the wheel. The market doesn't want proprietary anymore, they want standards and mobility. Configuration of the server should happen through MBeans. You can wrap that in gfsh for command line, REST for remote web based ad

Re: Simple Java Client

For clarification, the Management REST API [1] is not the Developer REST API [2]. These are 2 separate/different thin

Re: Simple Java Client

A couple of points to interact with John's points. GFSH as API We agree that GFSH is a DSL, and a really good and useful one. We agree that we don't want our API tied to GFSH syntax. I view the valuable part of GemFire admin as the Java code underneath GFSH, or the "Commands." For example, to cr

Re: Simple Java Client

I agree with John's points here -- and, by extension, Dan's points. :) On Tue, Apr 25, 2017 at 4:00 PM, John Blum wrote: > > *Naming convention: Geode's region is a Cache in JSR-107, and Geode's > Cache is a CacheManager. I think it would be too confusing to change the > meaning of cache. Also,

Re: Simple Java Client

Good feedback. This would use the new protocol. I should have mentioned that. The original driver for this was the Region API needs either an update or an alternative. Updating has a few drawbacks: Region wasn't designed with open source in-mind and as Swap mentioned it is naturally tightly cou

Re: Simple Java Client

> *Naming convention: Geode's region is a Cache in JSR-107, and Geode's Cache is a CacheManager. I think it would be too confusing to change the meaning of cache. Also, how do you document this given that Cache means different things if you are talking JCache vs Geode.* Perhaps something similar t

Re: Simple Java Client

I had looked at the JCache in the past and here are some of the things I noted: Naming convention: Geode's region is a Cache in JSR-107, and Geode's Cache is a CacheManager. I think it would be too confusing to change the meaning of cache. Also, how do you document this given that Cache means diff

Re: Simple Java Client

Agree with Dan... If we are trying to come-up with APIs that is useful for PCF, probably what Wes has (wrapper around gfsh) approach may suffice... As Dan was suggesting we should have generic approach (pcf and non-pcf users); and many of the things can be accomplished by using existing code-base

Re: Simple Java Client

What transport are you planning on using? REST, or the current binary protocol? Or is this just a wrapper around the existing java client APIs? If this about creating a new API, I agree with what John is saying that we need reduce the number of APIs we have to do the same thing in java. It seems e

Re: Simple Java Client

Hi Fred- As an FYI, sometime ago now so I don't recall all the details, but I have had several users/community developers ask me (online, @conferences, etc) when/if ever Geode was considering implementing the *JCache* API. I definitely think there is value in doing so. One of the major concerns

Re: Simple Java Client

That's great, Wes. I will take a look. Thanks. John -- good feedback to consider and I was hoping this would come up. "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/applicatio

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 c

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 u

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 library that provides 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

e device.. > > > > From: Michael Stolz > 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. > > &g

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 intera

Re: Simple Java Client

I would imagine rest client for mobile device.. From: Michael Stolz 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

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 c

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) completely new API

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 P