@Eric-
Hmm...
Well, I'd argue that it is still confusing to "*overload*" the purpose of
getRegion("path") to dually "*get*" (the primary function/purpose) and also
"*create*" (secondary).
I'd also say that the getRegion("path") API call is not exclusive to a
*ClientCache*, particularly since getRegion("path") is on RegionService
<http://data-docs-samples.cfapps.io/docs-gemfire/latest/javadocs/japi/com/gemstone/gemfire/cache/RegionService.html#getRegion(java.lang.String)>
[1],
which both ClientCache and Cache implement, indirectly through GemFireCache,
I might add. Therefore, getRegion("path") has a completely different
meaning server-side (or in the embedded "peer cache" UC).
-j
[1]
http://data-docs-samples.cfapps.io/docs-gemfire/latest/javadocs/japi/com/gemstone/gemfire/cache/RegionService.html#getRegion(java.lang.String)
On Wed, Feb 15, 2017 at 9:29 AM, Anthony Baker <aba...@pivotal.io> wrote:
> Introducing an API like this gives us the opportunity to split the
> client/server region API’s. I don’t think we should return Region, but
> something specific to “server view”. How would those API’s operate on a
> CACHING_PROXY?
>
> Anthony
>
> > On Feb 15, 2017, at 6:44 AM, Swapnil Bawaskar <sbawas...@pivotal.io>
> wrote:
> >
> > /**
> > * @return
> > */
> > Region<K, V> serverView();
> >
>
>
--
-John
john.blum10101 (skype)
