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, consistent.
Separate, and standard based, management is also a must. Configuration based on MBeans opens the doors to many configuration and management tools already in the marketplace that we don't have to write and support ourselves. We can then focus on what we do best which is consistent distributed data, not management platforms. -Jake On Thu, Apr 27, 2017 at 4:19 PM Swapnil Bawaskar <sbawas...@pivotal.io> wrote: > 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), I then tried to use the EntryProcessor mentioned in the book, > but Geode does not support that. Supporting a standard would only become an > exercise in getting a checkmark in a feature comparison. BTW, we are stuck > with "Region" because of the initial drafts of JSR-107. Geode is much more > than a "Cache", a number of users treat it as a system of record. > Implementing JSR-107 would be a step backward. I would have been onboard > implementing JSR-347 "Data grids for Java > <https://jcp.org/en/jsr/detail?id=347>, unfortunately, it was withdrawn. > Rather than renaming "Region" to "Cache", if we do have to rename it, we > should just call it a Map. Then add other data structures like Lists and > Sorted Sets. > > On Thu, Apr 27, 2017 at 2:21 PM Kirk Lund <kl...@pivotal.io> wrote: > > > "geode-client-api.jar" (not ai) > > > > On Thu, Apr 27, 2017 at 2:20 PM, Kirk Lund <kl...@pivotal.io> 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 Schuchardt < > > bschucha...@pivotal.io> > > > wrote: > > > > > >> 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 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.api -- the main rich API (geode-api module and jar) > > >>> org.apache.geode.api.client -- the new thin client API > > (geode-api-client > > >>> module and jar) > > >>> org.apache.geode.core -- the main implementation of api (geode-core > > >>> module > > >>> and jar which also currently contains the old API) > > >>> > > >>> On Wed, Apr 26, 2017 at 9:41 AM, William Markito Oliveira < > > >>> william.mark...@gmail.com> wrote: > > >>> > > >>> 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 that well exposed, known by others > or > > >>>> obscured by some decisions that doesn't apply anymore. > > >>>> > > >>>> It's the same conversation about monitoring and statistics... All > the > > >>>> capability is there with JMX and Stats, but using an unknown custom > > >>>> format > > >>>> or tool to display that data makes it not very appealing for OSS and > > >>>> enterprise users that need workarounds and hacks to integrate with > > >>>> common > > >>>> monitoring tools. > > >>>> > > >>>> Refactoring API Client APIs, documentation and implementation of a > new > > >>>> Protocol, Reactive APIs, better integration with standard monitoring > > >>>> tools > > >>>> - Sounds like good points for a 2.0 roadmap IMHO. > > >>>> > > >>>> > > >>>> On Wed, Apr 26, 2017 at 10:28 AM, Jacob Barrett < > jbarr...@pivotal.io> > > >>>> wrote: > > >>>> > > >>>> 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 <wwilli...@pivotal.io > > > > >>>>> > > >>>> wrote: > > >>>> > > >>>>> 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- > > >>>>>> > > >>>>> > core/src/main/java/org/apache/geode/management/internal/cli/commands > > >>>>> > > >>>>>> Or somewhere else? > > >>>>>> > > >>>>>> *Wes Williams | Pivotal Advisory **Data Engineer* > > >>>>>> 781.606.0325 <(781)%20606-0325> > > >>>>>> http://pivotal.io/big-data/pivotal-gemfire > > >>>>>> > > >>>>>> On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett < > > jbarr...@pivotal.io> > > >>>>>> wrote: > > >>>>>> > > >>>>>> 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 admin, use > > >>>>>>> > > >>>>>> JConsole > > >>>> > > >>>>> or > > >>>>>> > > >>>>>>> any other number of JMX based enterprise management tools. By > using > > >>>>>>> > > >>>>>> MBeans > > >>>>>> > > >>>>>>> the server can easily expose new discovered services without the > > need > > >>>>>>> > > >>>>>> to > > >>>>> > > >>>>>> code specific gfsh commands, REST interfaces or APIs. There is no > > >>>>>>> > > >>>>>> reason > > >>>>> > > >>>>>> my > > >>>>>> > > >>>>>>> SDG can't be retooled to "discover" the configuration from these > > >>>>>>> > > >>>>>> MBeans > > >>>> > > >>>>> as > > >>>>>> > > >>>>>>> well rather than having to be touched every time we add or change > > >>>>>>> something. There are tools and books already written that > > >>>>>>> > > >>>>>> implementors > > >>>> > > >>>>> can > > >>>>>> > > >>>>>>> consult on MBeans. There isn't anything out there on gfsh > commands. > > >>>>>>> > > >>>>>>> If we want to play in the Java community, especially J2EE (the > > other > > >>>>>>> > > >>>>>> 50% > > >>>>> > > >>>>>> of > > >>>>>> > > >>>>>>> Java that isn't Spring), then we had better have a JSR-107 answer > > no > > >>>>>>> > > >>>>>> matter > > >>>>>> > > >>>>>>> what the pain is to provide it. I can pull dozens of books of the > > >>>>>>> > > >>>>>> shelf > > >>>> > > >>>>> that teach me how to effectively use a JCache, how many can I pull > > >>>>>>> > > >>>>>> off > > >>>> > > >>>>> the > > >>>>>> > > >>>>>>> shelf that teach me Geode's API? How many engineers can I get > > >>>>>>> > > >>>>>> applications > > >>>>>> > > >>>>>>> form by saying "must have Geode API knowledge"? I can find people > > >>>>>>> > > >>>>>> with > > >>>> > > >>>>> JCache knowledge though. So from in implementor's perspective > having > > >>>>>>> standards is a must. Now I don't think the JSR-107 interface > should > > >>>>>>> > > >>>>>> be > > >>>> > > >>>>> the > > >>>>>> > > >>>>>>> root interface but rather a facade on the "raw" Geode proprietary > > bad > > >>>>>>> > > >>>>>> ass > > >>>>> > > >>>>>> API. That API should be 100% asynchronous (reactive, SEDA, > whatever > > >>>>>>> > > >>>>>> the > > >>>> > > >>>>> current buzzword for asynchronous is today). Around that API we can > > >>>>>>> > > >>>>>> provide > > >>>>>> > > >>>>>>> facades for JSR 107, ConcurrentMap (our current yet not so well > > >>>>>>> > > >>>>>> behaving > > >>>>> > > >>>>>> API), List, Queue, etc. Maybe even JPA, JCA, etc. The thought of > > >>>>>>> > > >>>>>> putting > > >>>>> > > >>>>>> all those features into a single API makes my head exploded and > they > > >>>>>>> > > >>>>>> don't > > >>>>>> > > >>>>>>> need to be like they are today. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Tue, Apr 25, 2017 at 8:25 PM Wes Williams < > wwilli...@pivotal.io > > > > > >>>>>>> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> 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 create a JAVA API to "Create Region", why not > > >>>>>>>> > > >>>>>>> create a > > >>>>> > > >>>>>> Java API around CreateAlterDestroyRegionCommands? In this way, > > >>>>>>>> > > >>>>>>> GFSH > > >>>> > > >>>>> and > > >>>>> > > >>>>>> the > > >>>>>>> > > >>>>>>>> JAVA API share the same code. It seems too obvious yet I don't > see > > >>>>>>>> > > >>>>>>> it > > >>>> > > >>>>> being > > >>>>>>> > > >>>>>>>> recommended. Why not? (Note: the hard-coded formatting would > > need > > >>>>>>>> > > >>>>>>> to > > >>>>> > > >>>>>> be > > >>>>>> > > >>>>>>> removed). > > >>>>>>>> > > >>>>>>>> Once you have the Java/GFSH/REST API as common code, you then > > >>>>>>>> > > >>>>>>> refactor > > >>>>> > > >>>>>> it. > > >>>>>>> > > >>>>>>>> What's the objection to this approach? Once you open Java API's > to > > >>>>>>>> > > >>>>>>> do > > >>>> > > >>>>> everything that GFSH does, then you have now unshackled the power > > >>>>>>>> > > >>>>>>> of > > >>>> > > >>>>> the > > >>>>>> > > >>>>>>> developer (the JAVA API) and the admin (GFSH API). > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> REST API > > >>>>>>>> > > >>>>>>>> I've found that most don't want to use the Dev REST API because > > >>>>>>>> > > >>>>>>> it's > > >>>> > > >>>>> attached to a server rather than the cluster. HA? > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> *Wes Williams | Pivotal Advisory **Data Engineer* > > >>>>>>>> 781.606.0325 <(781)%20606-0325> <(781)%20606-0325> > > >>>>>>>> http://pivotal.io/big-data/pivotal-gemfire > > >>>>>>>> > > >>>>>>>> On Tue, Apr 25, 2017 at 7:01 PM, Fred Krone <fkr...@pivotal.io> > > >>>>>>>> > > >>>>>>> wrote: > > >>>>> > > >>>>>> 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 > > >>>>>>>>> > > >>>>>>>> coupled. > > >>>>>>>> > > >>>>>>>>> Members of the community are already working to update Region > but > > >>>>>>>>> > > >>>>>>>> something > > >>>>>>>> > > >>>>>>>>> gets fixed and it breaks something for someone else. I think > > >>>>>>>>> > > >>>>>>>> it's > > >>>> > > >>>>> much > > >>>>>> > > >>>>>>> better to provide a new interface that implements the first part > > >>>>>>>>> > > >>>>>>>> of > > >>>> > > >>>>> JSR > > >>>>>> > > >>>>>>> 107 > > >>>>>>>> > > >>>>>>>>> (javax.cache) and get the ball rolling for the community and, > > >>>>>>>>> > > >>>>>>>> perhaps, > > >>>>>> > > >>>>>>> over > > >>>>>>>> > > >>>>>>>>> time deprecate Region (although that's not a primary > objective). > > >>>>>>>>> > > >>>>>>>>> A Java driver will probably get built regardless just to give > the > > >>>>>>>>> > > >>>>>>>> new > > >>>>> > > >>>>>> protocol some legs. That driver also needs a decent caching > > >>>>>>>>> > > >>>>>>>> interface. > > >>>>>> > > >>>>>>> JSR > > >>>>>>>> > > >>>>>>>>> 107 has already solved that part. So let's get started on it. > > >>>>>>>>> > > >>>>>>>> If > > >>>> > > >>>>> the > > >>>>>> > > >>>>>>> community wants to go the whole way and continue JSR 107 > > >>>>>>>>> > > >>>>>>>> implementation > > >>>>>> > > >>>>>>> after that that's awesome. Functions can also be added, etc. > > >>>>>>>>> > > >>>>>>>>> I intentionally did not mention anything about PCF as this > > >>>>>>>>> > > >>>>>>>> pertains > > >>>> > > >>>>> to > > >>>>>> > > >>>>>>> Geode itself as an open source offering and developer experience. > > >>>>>>>>> > > >>>>>>>> I'm > > >>>>>> > > >>>>>>> writing as a member of the community. Ie: I'm a developer who > > >>>>>>>>> > > >>>>>>>> would > > >>>> > > >>>>> like > > >>>>>>> > > >>>>>>>> to > > >>>>>>>> > > >>>>>>>>> add some caching to my application -- I can download either > Geode > > >>>>>>>>> > > >>>>>>>> or > > >>>>> > > >>>>>> Hazelcast for free and right now it's a no brainer. Not that we > > >>>>>>>>> > > >>>>>>>> wouldn't > > >>>>>>> > > >>>>>>>> keep PCF in-mind but it's out of scope for this thread. I do > > >>>>>>>>> > > >>>>>>>> believe > > >>>>> > > >>>>>> getting started on a Java driver for the protocol and a > > >>>>>>>>> > > >>>>>>>> standardized > > >>>>> > > >>>>>> caching API are easily leveraged wins across the board. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Tue, Apr 25, 2017 at 3:20 PM, Swapnil Bawaskar < > > >>>>>>>>> > > >>>>>>>> sbawas...@pivotal.io> > > >>>>>>> > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> 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 > > >>>>>>>>>> > > >>>>>>>>> different > > >>>>>>>> > > >>>>>>>>> things if you are talking JCache vs Geode. > > >>>>>>>>>> > > >>>>>>>>>> The way to create a Cache in JSR-107 is: > > >>>>>>>>>> Cache<Integer, Date> cache = manager.createCache(cacheName, > > >>>>>>>>>> > > >>>>>>>>> Configuration > > >>>>>>>> > > >>>>>>>>> c); > > >>>>>>>>>> Where it is upto the implementation to extend Configuration. > > >>>>>>>>>> > > >>>>>>>>> Given > > >>>>> > > >>>>>> this, > > >>>>>>>> > > >>>>>>>>> users will not be able to switch from an existing > > >>>>>>>>>> > > >>>>>>>>> implementation > > >>>> > > >>>>> to > > >>>>> > > >>>>>> ours; > > >>>>>>>> > > >>>>>>>>> will have to write new code specially Configuration, making > > >>>>>>>>>> > > >>>>>>>>> callbacks > > >>>>>> > > >>>>>>> serializable etc. > > >>>>>>>>>> > > >>>>>>>>>> JSR-107 will not be limited to the client. Server side > > >>>>>>>>>> > > >>>>>>>>> callbacks > > >>>> > > >>>>> like > > >>>>>> > > >>>>>>> CacheLoader, CacheListener etc. will need handle on jsr-107 > > >>>>>>>>>> > > >>>>>>>>> “cache”. > > >>>>>> > > >>>>>>> JSR-107 supports features like an EntryProcessor, which is a > > >>>>>>>>>> > > >>>>>>>>> function > > >>>>>> > > >>>>>>> invoked atomically on an entry operation. We will have to make > > >>>>>>>>>> > > >>>>>>>>> invasive > > >>>>>>> > > >>>>>>>> changes to Geode to support this. > > >>>>>>>>>> > > >>>>>>>>>> Given these, I don't think supporting JSR-107 is trivial. > > >>>>>>>>>> > > >>>>>>>>>> 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 > > >>>>>>>>>>> > > >>>>>>>>>> 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 especially confusing if we end up with different APIs > > >>>>>>>>>>> > > >>>>>>>>>> that > > >>>>> > > >>>>>> support > > >>>>>>>>> > > >>>>>>>>>> distinct features - like being able to create a region on the > > >>>>>>>>>>> > > >>>>>>>>>> server > > >>>>>>> > > >>>>>>>> with > > >>>>>>>>> > > >>>>>>>>>> this new API but only being able to invoke a function with > > >>>>>>>>>>> > > >>>>>>>>>> the > > >>>> > > >>>>> old > > >>>>>> > > >>>>>>> API. > > >>>>>>>> > > >>>>>>>>> The other thing I think we need to avoid is being able to do > > >>>>>>>>>>> > > >>>>>>>>>> things > > >>>>>> > > >>>>>>> from > > >>>>>>>>> > > >>>>>>>>>> the client (or gfsh, or xml, ...) that don't have a java API > > >>>>>>>>>>> > > >>>>>>>>>> on > > >>>> > > >>>>> the > > >>>>>> > > >>>>>>> server. > > >>>>>>>>>> > > >>>>>>>>>>> I'm assuming your getOrCreateRegion region is supposed behave > > >>>>>>>>>>> > > >>>>>>>>>> like > > >>>>>> > > >>>>>>> the > > >>>>>>>> > > >>>>>>>>> gfsh > > >>>>>>>>>> > > >>>>>>>>>>> command and update the cluster configuration? +++1 to Wes's > > >>>>>>>>>>> > > >>>>>>>>>> suggestion > > >>>>>>>> > > >>>>>>>>> have > > >>>>>>>>>> > > >>>>>>>>>>> a public API for executing these gfsh operations. > > >>>>>>>>>>> > > >>>>>>>>>>> I really think we need to work on having *one* authoritative > > >>>>>>>>>>> > > >>>>>>>>>> public > > >>>>>> > > >>>>>>> API > > >>>>>>>> > > >>>>>>>>> that contains everything that we support on the server. The > > >>>>>>>>>>> > > >>>>>>>>>> protocols > > >>>>>>> > > >>>>>>>> we > > >>>>>>>>> > > >>>>>>>>>> support (REST, binary, ...) and the client drivers that use > > >>>>>>>>>>> > > >>>>>>>>>> those > > >>>>> > > >>>>>> protocols > > >>>>>>>>>> > > >>>>>>>>>>> should just be ways of accessing that API. The Java API on > > >>>>>>>>>>> > > >>>>>>>>>> the > > >>>> > > >>>>> server > > >>>>>>> > > >>>>>>>> right > > >>>>>>>>>> > > >>>>>>>>>>> now the closest thing we have to this, but there are things > > >>>>>>>>>>> > > >>>>>>>>>> you > > >>>> > > >>>>> can > > >>>>>> > > >>>>>>> do > > >>>>>>>> > > >>>>>>>>> with > > >>>>>>>>>> > > >>>>>>>>>>> gfsh and things you can do with the current client that have > > >>>>>>>>>>> > > >>>>>>>>>> no > > >>>> > > >>>>> java > > >>>>>>> > > >>>>>>>> API > > >>>>>>>>> > > >>>>>>>>>> equivalent. I think we really need to fix that! > > >>>>>>>>>>> > > >>>>>>>>>>> Also, preferably we won't have to hand code a bunch of stuff > > >>>>>>>>>>> > > >>>>>>>>>> in > > >>>> > > >>>>> every > > >>>>>>> > > >>>>>>>> client driver and protocol whenever we add a new feature. For > > >>>>>>>>>>> > > >>>>>>>>>> example > > >>>>>>> > > >>>>>>>> if > > >>>>>>>>> > > >>>>>>>>>> were to add a geode function to invoke each new API we add, > > >>>>>>>>>>> > > >>>>>>>>>> that > > >>>>> > > >>>>>> new > > >>>>>>> > > >>>>>>>> API > > >>>>>>>>> > > >>>>>>>>>> would be accessible from REST, gfsh, the java client etc. > > >>>>>>>>>>> > > >>>>>>>>>> Later > > >>>> > > >>>>> we > > >>>>>> > > >>>>>>> could > > >>>>>>>>> > > >>>>>>>>>> add syntatic sugar to make the new API prettier, but if we > > >>>>>>>>>>> > > >>>>>>>>>> had > > >>>> > > >>>>> a > > >>>>> > > >>>>>> low > > >>>>>>> > > >>>>>>>> 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. > > >>>>>>>>>>> > > >>>>>>>>>>> Supporting JSR-107 might be nice - but that could probably > > >>>>>>>>>>> > > >>>>>>>>>> be > > >>>> > > >>>>> written > > >>>>>>>> > > >>>>>>>>> just > > >>>>>>>>>> > > >>>>>>>>>>> as a wrapper 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 features > > >>>>>>>>>>> > > >>>>>>>>>> they > > >>>>>> > > >>>>>>> should > > >>>>>>>>> > > >>>>>>>>>> drop into the existing API. > > >>>>>>>>>>> > > >>>>>>>>>>> I also like the idea of a smaller client jar and > > >>>>>>>>>>> > > >>>>>>>>>> dependencies, > > >>>> > > >>>>> but > > >>>>>> > > >>>>>>> I > > >>>>>>> > > >>>>>>>> think > > >>>>>>>>>> > > >>>>>>>>>>> there is a huge amount of room for improvement 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...@pivotal.io > > >>>> > > >>>>> wrote: > > >>>>>>>> > > >>>>>>>>> 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/applications are the new concurrency), then I > > >>>>>>>>>>>> > > >>>>>>>>>>> am > > >>>>> > > >>>>>> really > > >>>>>>>> > > >>>>>>>>> saying the same thing." > > >>>>>>>>>>>> > > >>>>>>>>>>>> This would be cover non spring and 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 > > >>>>>>>> > > >>>>>>>>> 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 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 > > >>>>>>>>>>>>> > > >>>>>>>>>>>> similarities > > >>>>>>> > > >>>>>>>> and > > >>>>>>>>> > > >>>>>>>>>> differences for your goal. This project creates both > > >>>>>>>>>>>>> > > >>>>>>>>>>>> server > > >>>> > > >>>>> and > > >>>>>> > > >>>>>>> client > > >>>>>>>>>> > > >>>>>>>>>>> regions dynamically. It lists regions, alters regions… > > >>>>>>>>>>>>> > > >>>>>>>>>>>> really > > >>>>>> > > >>>>>>> anything > > >>>>>>>>>> > > >>>>>>>>>>> that GFSH can do. It differs in that it calls GFSH to do > > >>>>>>>>>>>>> > > >>>>>>>>>>>> its > > >>>>> > > >>>>>> work > > >>>>>>> > > >>>>>>>> rather > > >>>>>>>>>>> > > >>>>>>>>>>>> than a Java interface. You can think of this as a Java > > >>>>>>>>>>>>> > > >>>>>>>>>>>> API > > >>>> > > >>>>> on > > >>>>> > > >>>>>> top > > >>>>>>> > > >>>>>>>> of > > >>>>>>>>> > > >>>>>>>>>> GFSH. > > >>>>>>>>>>>> > > >>>>>>>>>>>>> You can use this model and keep the similarities while > > >>>>>>>>>>>>> > > >>>>>>>>>>>> adjusting > > >>>>>>> > > >>>>>>>> for > > >>>>>>>>> > > >>>>>>>>>> the > > >>>>>>>>>>> > > >>>>>>>>>>>> Java interface. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Similarities > > >>>>>>>>>>>>> - Client uses SDG and complies with JSR-107 > > >>>>>>>>>>>>> [the Cache Manager is here: > > >>>>>>>>>>>>> > > >>>>>>>>>>>> https://github.com/Pivotal- > > >>>>> > > >>>>>> Data-Engineering/ClusterManagement/tree/master/ > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > cluster-management-client/src/main/java/com/geode/cache/mana > > >>>>>> ger > > >>>>>> > > >>>>>>> ] > > >>>>>>> > > >>>>>>>> - After the server creates its region, client creates its > > >>>>>>>>>>>>> > > >>>>>>>>>>>> region > > >>>>>>> > > >>>>>>>> [ see createRegions at: https://github.com/Pivotal- > > >>>>>>>>>>>>> > > >>>>>>>>>>>> Data-Engineering/ > > >>>>>>>>>>>> > > >>>>>>>>>>>>> ClusterManagement/blob/master/cluster-management- > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> client/src/main/java/com/geode/cache/manager/ > > >>>>>>>>>>> > > >>>>>>>>>> RegionCreator.java<https:// > > >>>>>>>>> > > >>>>>>>>>> github.com/Pivotal-Data-Engineering/ClusterManagement/ > > >>>>>>>>>>>>> > > >>>>>>>>>>>> blob/master/cluster- > > >>>>>>>>>>>> > > >>>>>>>>>>>>> management-client/src/main/java/com/geode/cache/manager/ > > >>>>>>>>>>>>> > > >>>>>>>>>>>> RegionCreator.java> > > >>>>>>>>>>>> > > >>>>>>>>>>>>> ] > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Differences > > >>>>>>>>>>>>> Server dynamically calls GFSH to execute commands > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> How it works > > >>>>>>>>>>>>> - Whenever the client calls a region that does not exist, > > >>>>>>>>>>>>> > > >>>>>>>>>>>> the > > >>>>> > > >>>>>> client > > >>>>>>>>> > > >>>>>>>>>> looks > > >>>>>>>>>>>> > > >>>>>>>>>>>>> for a <region name>.properties file. If the properties > > >>>>>>>>>>>>> > > >>>>>>>>>>>> file > > >>>> > > >>>>> exists, > > >>>>>>>> > > >>>>>>>>> the > > >>>>>>>>>> > > >>>>>>>>>>> region is created with the dynamic properties. > > >>>>>>>>>>>>> - If <region name>.properties does not exist, default > > >>>>>>>>>>>>> > > >>>>>>>>>>>> region > > >>>>> > > >>>>>> properties > > >>>>>>>>>> > > >>>>>>>>>>> are loaded and used to create the region. > > >>>>>>>>>>>>> - properties are formed into a GFSH string and passed to > > >>>>>>>>>>>>> > > >>>>>>>>>>>> a > > >>>> > > >>>>> server > > >>>>>>> > > >>>>>>>> function > > >>>>>>>>>>>> > > >>>>>>>>>>>>> - The server function calls GFSH using internal calls. It > > >>>>>>>>>>>>> > > >>>>>>>>>>>> calls > > >>>>>> > > >>>>>>> the > > >>>>>>>> > > >>>>>>>>> GfshParser, executes the command, and then returns the > > >>>>>>>>>>>>> > > >>>>>>>>>>>> parsed > > >>>>> > > >>>>>> results. > > >>>>>>>>>> > > >>>>>>>>>>> [see https://github.com/Pivotal-Data-Engineering/ > > >>>>>>>>>>>>> ClusterManagement/blob/master/ > > >>>>>>>>>>>>> > > >>>>>>>>>>>> cluster-management-server/src/ > > >>>>> > > >>>>>> main/java/com/geode/gfsh/GfshCommand.java] > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Limitations > > >>>>>>>>>>>>> It uses internal calls to call GFSH. I have made requests > > >>>>>>>>>>>>> > > >>>>>>>>>>>> to > > >>>>> > > >>>>>> make > > >>>>>>> > > >>>>>>>> this > > >>>>>>>>>> > > >>>>>>>>>>> a > > >>>>>>>>>>> > > >>>>>>>>>>>> stable public interface. Andrew Baker had a good idea to > > >>>>>>>>>>>>> > > >>>>>>>>>>>> return > > >>>>>> > > >>>>>>> gfsh > > >>>>>>>>> > > >>>>>>>>>> results in JSON format with a new —results=json property > > >>>>>>>>>>>>> > > >>>>>>>>>>>> to > > >>>> > > >>>>> pass > > >>>>>>> > > >>>>>>>> to > > >>>>>>>> > > >>>>>>>>> GFSH. > > >>>>>>>>>>> > > >>>>>>>>>>>> Strengths > > >>>>>>>>>>>>> That is uses GFSH can be viewed as a strength to keep a > > >>>>>>>>>>>>> > > >>>>>>>>>>>> consistent > > >>>>>>>> > > >>>>>>>>> API, > > >>>>>>>>>> > > >>>>>>>>>>> whether Java or GFSH > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> TESTS > > >>>>>>>>>>>>> You can start by running server tests at: > > >>>>>>>>>>>>> > > >>>>>>>>>>>> https://github.com/Pivotal- > > >>>>>>>>>> > > >>>>>>>>>>> Data-Engineering/ClusterManagement/tree/master/ > > >>>>>>>>>>>>> cluster-management-server/src/test/java/com/geode/gfsh > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Client tests are at: > > >>>>>>>>>>>>> > > >>>>>>>>>>>> https://github.com/Pivotal-Data-Engineering/ > > >>>>>>>> > > >>>>>>>>> ClusterManagement/tree/master/ > > >>>>>>>>>>>>> > > >>>>>>>>>>>> cluster-management-client/src/ > > >>>>> > > >>>>>> test/java/com/geode/management/client > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Regards, > > >>>>>>>>>>>>> Wes Williams > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On Apr 24, 2017, at 6:51 PM, Kirk Lund <kl...@apache.org > > >>>>>>>>>>>>> > > >>>>>>>>>>>> <mailto: > > >>>>>>> > > >>>>>>>> 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 < > > >>>>>>>>>>>>> > > >>>>>>>>>>>> fkr...@pivotal.io > > >>>>>> > > >>>>>>> <mailto: > > >>>>>>>>>> > > >>>>>>>>>>> fkro > > >>>>>>>>>>> > > >>>>>>>>>>> > > > > > >
