+1 On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols <onich...@pivotal.io> wrote:
> +1 > > > On Nov 18, 2019, at 3:00 PM, Nabarun Nag <n...@pivotal.io> wrote: > > > > +1 > > > > On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer <u...@apache.com> wrote: > > > >> Thank you for this Bill, > >> > >> I must admit that I'm starting to get a feeling of "scope creep" here.. > >> I understand that all efforts to "modularize" membership would require > >> some form of peripheral decoupling. > >> > >> BUT > >> > >> I'm starting to get concerned that we are hitting a rabbit hole > >> scenario. Maybe this is normal for an effort of this manner, BUT, I > >> would like to urge that we start discussing/proposing other > >> modulizations, like, Serialization and now TCP communications as real > >> modules with own proposals and with their own merit. > >> > >> YES, I understand this is minimal touch modulizations, but I'm concerned > >> that we are doing work under the incorrect banner. Just enough to > >> complete one "piece of it", but possibly a rework, of the module because > >> of the "good enough" approach we take. > >> > >> Maybe we are discovering that there is some pre-work that needed to have > >> been completed before the whole membership modularization effort was > >> started.. And maybe this is the time where we need to take a step back, > >> look at this from a higher perspective and decide if membership is > >> really still the priority here with serialization and transport > >> (TCPServer) being a side-effect. > >> > >> For this reason alone I vote: *-0 *on this matter.. (it is only a little > >> better than -1) > >> > >> --Udo > >> > >> On 11/18/19 1:48 PM, Bill Burcham wrote: > >>> Dear Geode, > >>> > >>> In support of the Membership modularization efforts > >>> > >> > https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project > >> , > >>> we would like to move the types in the > >>> org.apache.geode.distributed.internal.tcpserver package (i.e. the > >> TcpServer > >>> class and related types) into a separate module in order to eliminate > >>> dependencies on geode-core. > >>> > >>> The membership subsystem is dependent on this group of types, which in > >> turn > >>> are (were) highly-dependent on geode-core. We have been systematically > >>> eliminating dependencies from these types to geode-core as part of > >>> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not > >>> depend on geode-core_ The final sub-task on that ticket puts TcpServer > >> and > >>> related types into its own separate module. > >>> > >>> The proposed module would be called "geode-tcp-server" and would > contain > >>> TcpServer and the other types in the > >>> org.apache.geode.distributed.internal.tcpserver package. > >>> > >>> Your feedback is welcomed and appreciated. > >>> > >>> Your Friend, > >>> Bill > >>> > >> > > -- *Joris Melchior * CF Engineering Pivotal Toronto 416 877 5427 “Programs must be written for people to read, and only incidentally for machines to execute.” – *Hal Abelson* <https://en.wikipedia.org/wiki/Hal_Abelson>
