Thanks for the feedback. We have rough consensus for the new module so we will make it so.
On Mon, Nov 18, 2019 at 5:34 PM Joris Melchior <jmelch...@pivotal.io> wrote: > +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> >
