Suggestion on Channel Classes

Fri Jul 17 13:05:36 EDT 2009

Trustin,

I think you have pegged it all very well, i.e., correctly, Trustin,  
and that real problem, I suspect, is that it is hard to do UML with  
the design pattern but the design pattern itself is just fine.  The  
comparison is attached.

I tend to be a minimalist, believing that we should only do what must  
be done and no more.  Clearly the extension of the Interface by the  
Sub-Interface is unnecessary here.  However, what is technically  
unnecessary in the design pattern becomes absolutely necessary when we  
use the Sub-Interface with polymorphism to get to the implementation  
of the abstract class.

I appreciate people who think otherwise and enjoy a good splash of  
unnecessary color and flourish as much as the next guy.  But my own  
work is minimalist in nature.  I deal with very, very complex systems  
and need to keep them as simple as possible.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.pdf
Type: application/pdf
Size: 54564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-dev/attachments/20090717/cbca36c7/attachment-0001.pdf 
-------------- next part --------------

I always learn the code before using a system.  The API is never  
enough for me.  (I learned Koine Greek to read the New Testament, not  
trusting the translators to be true to the text.)  I am a through-and- 
through, impossible, GEEK.  <g>

While my primary interest is in using Netty, in the near term my  
principal contribution probably will be just some artifacts useful to  
developers, if anyone.  In the long run, though, I think I will get  
the system in a deep way and have a top down understanding that  
includes the details from the bottom up that will be useful to the  
user.  That will take a while.

Mike

On Jul 16, 2009, at 5:26 PM, ??? (Trustin Lee) wrote:

> Hmm, I'm not sure yet why such a design is not a good idea.  Isn't it
> what Java interface is for?  Anyway, the problem is that it's  
> difficult
> to understand the large picture of class hierarchy at a glance, and we
> need to fix it.
>
> Those interfaces were introduced to:
>
>  * determine the underlying transport of the channel easily
>    (e.g. instanceof SocketChannel? instanceof DatagramChannel?)
>  * leverage covariant return types
>    (same applied to various ChannelFactory subtypes)
>
> What's interesting is that a user does not (and does not need to) know
> the existence of all these interfaces actually in many cases.  They  
> are
> mostly for advanced user's convenience.  Therefore, I think we don't
> really need to over-expose the complicated class hierarchy when
> introducing Netty to a beginner.
>
> However, well drawn diagrams will help a developer that tries to
> understand the internals of Netty quite a lot.  We do not have a
> developers guide yet, so it will be a great addition to Netty
> documentation and your diagrams will be very useful for such purpose.
>
> Firstly, let me try to reduce the complexity of APIviz diagrams in
> Javadoc so that a user doesn't get lost in a cluttered diagram.  We
> could continue the discussion on making the Netty internals easier to
> understand on the other hand as a separate documentation effort.   
> WDYT?
> I'm open to good ideas.
>
> Thanks,
> Trustin
>
> On 07/16/2009 01:02 AM, Mike McGrady wrote:
>> My point should have been thought through to a greater degree.
>>
>> Essentially, however, I noticed that in effect some classes
>> systematically are "extending" or "implementing" the same interface  
>> from
>> more than one direction, e.g., extending a class that implements an
>> interface and implementing an interface that extends the same
>> interface.  This does not look good to me and I came up with a too
>> rushed solution.  Not sure what should be done.  I am most  
>> interested in
>> your first suggestion.
>>
>> Mike
>>
>> On Jul 14, 2009, at 11:38 PM, ??? (Trustin Lee) wrote:
>>
>>> On 07/15/2009 03:29 PM, ??? (Trustin Lee) wrote:
>>>> Hi Mike,
>>>>
>>>> On 07/07/2009 08:14 AM, Michael McGrady wrote:
>>>>> The Netty Channel interface throughout the package uses the  
>>>>> following
>>>>> design pattern.
>>>>>
>>>>> The sub-interfaces are seemingly wholly unnecessary and over- 
>>>>> complicate
>>>>> understanding the design. This is seemingly true of all of the
>>>>> following
>>>>> interface extensions.
>>>>>
>>>>> Unless there is good reason to the contrary that I am not aware  
>>>>> of, I
>>>>> would deprecate these extensions and then get rid of them.  I  
>>>>> would not
>>>>> be surprised if I have missed some reason why these are necessary.
>>>>
>>>> I'm not sure I understood what you suggested correctly, but are you
>>>> suggesting to remove the channel interfaces that extends one or  
>>>> more
>>>> other channel interfaces?  If so, I agree.  For example,
>>>> LocalServerChannel should be replaced by the combination of  
>>>> LocalChannel
>>>> and ServerChannel.  The same change could be applied to
>>>> ServerSocketChannel and XnioServerChannel.  Let me know if this  
>>>> is what
>>>> you think (or not.)
>>>
>>> Or, did you mean XYZServerChannel doesn't need to extend XYZChannel?
>>> (e.g. LocalServerChannel does not extend LocalChannel)  It actually
>>> sounds more reasonable.
>>>
>>> Trustin
>>> _______________________________________________
>>> netty-dev mailing list
>>> netty-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-dev
>>
>> Mike McGrady
>> Principal Investigator AF081-028 AFRL SBIR
>> Senior Engineer
>> Topia Technology, Inc.
>> 1.253.720.3365
>> mmcgrady at topiatechnology.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> netty-dev mailing list
>> netty-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-dev
>
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev

Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc
1.253.720.3365
mmcgrady at topiatechnology.com