Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

2019-11-18 Thread Joris Melchior
+1

On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols  wrote:

> +1
>
> > On Nov 18, 2019, at 3:00 PM, Nabarun Nag  wrote:
> >
> > +1
> >
> > On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer  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*



Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

2019-11-18 Thread Owen Nichols
+1

> On Nov 18, 2019, at 3:00 PM, Nabarun Nag  wrote:
> 
> +1
> 
> On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer  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
>>> 
>> 



Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

2019-11-18 Thread Nabarun Nag
+1

On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer  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
> >
>


Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

2019-11-18 Thread Udo Kohlmeyer

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



Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

2019-11-18 Thread Dan Smith
+1

-Dan

On Mon, Nov 18, 2019 at 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
>


[DISCUSS] Move TcpServer and friends to new geode-tcp-server module

2019-11-18 Thread Bill Burcham
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