On Fri, Aug 26, 2011 at 9:47 PM, Alan D. Cabrera <[email protected]>wrote:
>
> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>
> > On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
> >> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
> >> What I have in mind is much more something like :
> >>
> >> void messageReceived( context )
> >> {
> >> ... // do something, updating the context, eventually setting a
> status
> >> controller.callNextFilter( context, currentFilter );
> >> ... // do something after the call
> >> }
> >>
> >> and in controller :
> >> void callNextFilter( Context context, Filter currentFilter )
> >> {
> >> Status status = context.getStatus();
> >> Map<Status, Filter> map = fsmMap.get( currentFilter );
> >> Filter nextFilter = map.get( status );
> >>
> >> nextFilter.messageReceived( context );
> >> }
> >> This strikes me as pretty complex, jmho. Also, I don't like the idea of
> forcing the filter to call the controller.callNextFilter() to make things
> work.
> > the alternative would be something like :
> >
> > void messageReceived( context )
> > {
> > ... // do something, updating the context, eventually setting a status
> > fsmMap.get( this ).get( status ).messageReceived( context );
> > ... // do something after the call
> > }
> >
> > No controller, but a long list of chained call.
>
> But we're still forcing the filter to participate in things that really
> should be the domain of the controller not the filter.
>
> With that said I think that an FSM where we have, here letters are filters:
>
> [outside filter] -> {A -> [state change decides to send to] -> B -> [state
> change decides to send to] -> C} -> [outside filter]
>
> is very confusing. What protocol would require that? Just an honest
> question; one does not come to my mind atm.
>
> > Also the fsmMap must be known by the current filter.
> >> Look at my implementation of org.apache.mina.link.DownState as an
> example. This framework does not require a call to a controller for the
> whole thing to work. This filter merely focuses on its task at hand and
> implementation does not leak as much into its message received method.
> >
> > Ok, I'll give it a look.
> >>
> >>> The controller will decide which filter must be called depending on the
> context status.
> >>>
> >>> (Note that the controller should also decide which message to call, for
> instance, it can decide that it has to call a messageReceived() because it's
> caller was processing a messageReceived())
> >> I feel that, for the most part, we all have been doing a lot of
> discussions without any mock implementations of real protocols to help us
> gauge our API decisions.
> > I'm "lucky" enough to have played with MINA for more than 5 years, facing
> many differents kind of protocol based on it, plus having answered many of
> MINA user's questions regarding how to implement many different kind of
> protocol.
> >
> > Trust me on that, when I'm thinking about the new API, I always have in
> mind the different "real world" protocols we have to deal with. That
> includes :
> > - obviously LDAP protocol, which is a binary, two layer codec, demuxed
> protocol
> > - NTP based on UDP
> > - Kerberos based on UDP *and* TCP
> > - HTTP, ie newline terminated decoder, a cumulative decoder
> > - a few proprietary protocole implemented using MINA, with fixed size
> data, or LV type PDUs
>
> I think you missed my point. I am not questioning anyone's expertise in
> the industry. I am calling out the current modus operandi of the current
> API design process and it's need for real world mockups.
>
> >> Our tendency is to dive into the implementation details and then
> shoehorn protocols into the resultant API.
> > Not exactly my state of mind... I'm more trying to find the best possible
> solution, dealing with many constraints :
> > - ease of use
> > - coverage of the different use cases
> > - memory consumption
> > - ease of debuging
> > - speed
>
> Definitely good points. We all want this but they speak nothing to the
> process of coming up with an API. My point is to have concrete examples of
> how the API bits we are proposing would look. A perfect example is your and
> my ideas of how the FSM should work. With no concrete mocked up bits to see
> how the two APIs would influence the implementation of a protocol the
> discussion devolves into arguments over aesthetic opinions.
>
> >> This is why Mina 2 is so bloated and daunting.
> > MINA 2 is bloated for different reasons, and I think I have already
> discussed some of them.
> >
> > One of the most problematic reason is that MINA 2 (and 1) was a one man
> show. This is why I'm really pleased to have those discussion here, even if
> it seems to be a bike-shedding discussion. It is not.
>
+1
I'm glad to see these discussions. They're getting more and more concrete
every day.
>
> Agreed on the last bit. Anyone who thinks the current discussions about
> the API design are bike shed issues never designed an API.
>
> >> I'd like to see lots of little sandbox branches where people show what
> protocol implementations would end up looking like for the feature they are
> proposing. It's a fantastic way to gauge API design differences.
> > I like Julien's approach : designing a working solution, not covering all
> our bases right now, and implement a few existing protocols. Then moving
> forward.
>
> I'm sorry but that seems totally backwards to me. The API design should be
> the framework from which the working solution evolves. Starting with the
> implementations could automatically close the doors on useful API features.
>
>
+1
This methodology is a faster version of how MINA 2 evolved: out of need. It
might bind us to constructs that are not that easy to evolve out of as was
the case for MINA 2.
I agree with Alan about mock ups for various protocols because it will show
clearly which approach is cleaner. We can even benchmark performance and
also see if the debugging process is a PITA. It's the comprehensive way to
go. Let's face it the code base is small but getting the API right is hard.
Experimenting with multiple incarnations and implementations will show us
the best path.
--
Best Regards,
-- Alex
