t; >>>>>> caching API are easily leveraged wins across the board.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Apr 25, 2017 at 3:20 PM, Swapnil Bawaskar <
>
gt;
> >>>>>>>>> things
> >>>>>>>
> >>>>>>>> I
> >>>>>>>>
> >>>>>>>>> noted:
> >>>>>>>>>>
> >>>>>>>>>> Naming conv
;>
>>>>>>>>> the
>>>>>
>>>>>> meaning
>>>>>>>>>
>>>>>>>>>> of cache. Also, how do you document this given that Cache means
>>>>>>>>>>
>>>>
t;>>
>>>>>>>> Configuration
>>>>>>>
>>>>>>>> c);
>>>>>>>>> Where it is upto the implementation to extend Configuration.
>>>>>>>>>
>>>>>>>> Given
>
gt;>>>> CacheLoader, CacheListener etc. will need handle on jsr-107
> >>>>> “cache”.
> >>>>>>>>> JSR-107 supports features like an EntryProcessor, which is a
> >>>>> function
> >>>>>
>> 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
>
n'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
; > > > > 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. T
> that contains everything that we support on the server. The
> > > > protocols
> > > > > > we
> > > > > > > > support (REST, binary, ...) and the client drivers that use
> > those
> > > > > > > protocols
>
> > > > 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!
> > > > > > >
>
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
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 w
es, 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 Mo
es, 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.
> > > >
> &g
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 concurrency), t
, Fred Krone 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 onl
over 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 essentiall
> 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
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.
> >
> >
> >
> >
t; > 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&#x
opers 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.
>
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&
). 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 wrote:
>
> Here is a simple Java client _for enterprise use_ that I developed for
> Geode and distributed to several enterprises. It has similarit
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
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
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
> 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
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
+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
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
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
+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
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
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
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
cac
35 matches
Mail list logo
