geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <jb...@pivotal.io>
Subject Re: [PROPOSAL] Deprecating DistributedSystem
Date Thu, 29 Mar 2018 17:32:41 GMT
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 <gosullivan@apache.org>
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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message