Yes, framework and tooling. I see no reason why the functionality in o.a.g.distributed.DistributedSystem [1] should be hidden or internal. I would certainly remove the deprecated methods by now. A few other methods are questionable as to whether they really belong on the DistributedSystem interface, e.g. releaseThreadsSockets().
However, many of these methods are very useful, e.g. getDistributedMember(), findDistriubtedMember(..), and especially getProperties(). In general, I don't really get the need to have any internal/hidden classes in Geode and why most aspects of Geode should not be open and/or extensible, i.e. "*Open for Extension; Closed for Modification"... Open/Closed Principal [2]*). Most, if not all, APIs in Geode should have an interface and a provider implementation that is pluggable. I don't see why the DistributedSystem is any different. -j [1] http://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/DistributedSystem.html [2] https://en.wikipedia.org/wiki/Open/closed_principle On Thu, Mar 29, 2018 at 10:16 AM, Galen O'Sullivan <[email protected]> wrote: > It looks like there are a few JIRA tasks open to deprecate methods on > DistributedSystem, and it doesn't really have much functionality that would > be useful to a user. I propose that we deprecate DistributedSystem itself, > and keep the system management functionality internal. Is there any reason > why we shouldn't do this? > > Thanks, > Galen > -- -John john.blum10101 (skype)
