Salut,
Oleksiy Stashok wrote:
> Hi
>
>>> public static final int PORT = 7778;
>>> public void testStandaloneFilter() throws Exception {
>>> Connection connection = null;
>>> TCPNIOTransport transport =
>>> TransportManager.instance().createTCPTransport();
>>> transport.getFilterChain().add(new TransportFilter());
>>> transport.getFilterChain().add(new UTFStringFilter());
>>> transport.getFilterChain().add(new EchoFilter());
>>
>> We still need to discuss the getFilterChain() names ;-)
> :) ok
>
>>> try {
>>> transport.bind(PORT);
>>> transport.start();
>>> ConnectFuture future = transport.connectAsync("localhost",
>>> PORT);
>>> connection = (TCPNIOConnection) future.get(10,
>>> TimeUnit.SECONDS);
>>> assertTrue(connection != null);
>>> String message = "Hello world!";
>>> FilterChain filterChain = transport.getFilterChain();
>>> WriteResult result = filterChain.write(connection, message);
>>> assertEquals(result.getMessage(), message);
>>> ReadResult readResult = filterChain.read(connection);
>>
>> OK I'm not sure about this example. It seems we first works with the
>> Transport object and then switch to the FilterChain. If the
>> FilterChain handler the read/write logic, why not the connectAsync be
>> on the FilterChain as well?
> Well, I'm not trying to move transport logic to filterchain. I'm just
> showing how it's possible to use filterchain in standalone mode.
> How data could be read from the connection, pass the filterchain and
> finally we will have filterchain processed message (String in our case).
That's still confusing IMO. We should really have a single point of entry.
>
>
>> Also, the connet() operations returns A Future, where read/write
>> return a Read/WriteResult. Should read/write return a Future as well?
>> I would propose we unify the API so any async operations like
>> connect/read/write return a Future. From the Future, we can return a
>> Result, which contains the requested information. Something like:
> connectAsync is async operation, that's why it returns Future.
> read/write are blocking - that's why Result.
>
> readAsync/writeAsync operations return Future<Result>.
> So, IMHO, it's we don't have unification problems :)
Yes, but we should not make any difference between blocking or non
blocking. That will make things complicated and a long API (like we
currently have in 1.8.x). The shorter API we can have the better we will
be :-)
>
>
>> Result result = ConnectFuture.get()
>> Connection connection = result.getResult()
>>
>> or
>>
>> Connection connection = ConnectionFuture.get(..) //No cast needed
> that casting was redundant. Fixed.
>
>>
>> ReadResult result = ReadFuture.get();
>> WriteResult resukt = WriteFuture.get();
>>
>> So your example seems to "suffer" 2 issues:
>>
>> + Need one single Object to interact with.
> transport logic is inside Connection. And FilterChain just brings
> processing logic.
> The connection.read() in our example will return ByteBuffer, but
> filterchain.read() will return String (as result of UTFStringFilter).
Hum...I need to look at it more. I'm not sure as how can you know which
filter will return what? Meaning something like:
transport.getFilterChain().add(new TransportFilter());
transport.getFilterChain().add(new UTFStringFilter());
transport.getFilterChain().add(new LogFilter());
transport.getFilterChain().add(new EchoFilter());
How can I predict that readResult.getMessage() is coming from which Filter?
[Small thing] -> ReadResult should know what will be returned by doing
getMessage(), hence no need to cast IMO.
>
>> + Unify API for async operations.
> it's not problem :)
>
>
>>> String responseMessage = (String) readResult.getMessage();
>>> assertEquals(message, responseMessage);
>>> } finally {
>>> if (connection != null) {
>>> connection.close();
>>> }
>>> transport.stop();
>>> TransportManager.instance().close();
>>
>> I still find it dangerous to have 2 operations to execute here :-) But
>> maybe it is only me :-)
> No, no, you may be right. Just didn't time to revisit this.
I think we should start filling issue on 2.0 to not loose track. So far
we are only two discussing, but when every body is up to speed we will
loose content :-). What do you think?
A+
-- Jeanfrancois
>
> Thanks!
>
> WBR,
> Alexey.
>
>>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>> }
>>> }
>>> }
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>