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.
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.
Regards,
Alan
