>> wanted to share ideas John and myself came to, about changing
>> current Grizzly 2 I/O API.
>> The main idea is to make Grizzly 2.0 API to be based on
>> StreamReader/StreamWriter API, proposed by Ken. What does it mean?
>> Currently, to read something from Grizzly 2.0 Connection, we
>> perform following steps:
>> (1) Connect
>> /Future<Connection> connectionFuture = transport.connect(...);/
>> /connection = connectionFuture.get();/
>> (2) Allocate buffer
>> /Buffer buffer = transport.getMemoryManager().allocate(size);/
>> (3) Read data to buffer
>> /Future<ReadResult> readFuture = connection.read(buffer);/
>> /ReadResult result = readFuture.get();/
>> (4) Parse buffer
>> /if (buffer.remaining() >= 4) {/
>> / intValue = buffer.getInt();/
>> /}/
>> Similar steps we do for writing.
>> Concerns?
>> IMHO, there is one. We always have to care about allocating Buffers
>> and then, if we use some smart buffer pool, don't forget to release
>> it.
>
> I like the don't forget to release it :-) But should we still allow
> people to manipulate byte buffer, but also supports/recommend stream?
Sure, it will be possible, but not required.
>> ea is to use Streams for read and write operations. This will let
>> us hide Buffers complexity, developer will not need to care about
>> them anymore... and this should let us make Buffers usage more
>> optimal.
>> How read may look like with Streams?
>> (1) Connect
>> /Future<Connection> connectionFuture = transport.connect(...);/
>> /connection = connectionFuture.get();/
>> (2) Get StreamReader
>> /StreamReader reader = connection.getStreamReader();/
>> (3) Wait until data will become available
>> /Future future = reader.notifyAvailable(4);/
>> /future.get();/
>
> Should we have the CompletionHandler here as well so the
> Future.get() can be avoided (because blocking).
Yes, we can have several overloaded methods for notifyAvailable(...)
>> (4) Parse data from stream
>> /intValue = reader.getInt();/
>> As you see in Stream-like case we don't allocate any Buffer, so
>> Grizzly has complete control over a Buffer inside StreamReader.
>
> That seems OK but how will you implement a protocol like http using
> this? Would you support something like:
>
> read.readUntil('\r\n\r\n'); or the reader.read(byte[])?
>
> I would like to see the complete API picture here :-)
It will be possible to add by similar design as java.io streams have.
Like
SpecialStringReader reader = new
SpecialStringReader(connection.getInputReader());
reader.readUntil(....);
>> With write operation it's not so clear to me in terms of API,
>> because currently write works following way:
>> /Buffer buffer = transport.getMemoryManager().allocate(size);/
>> /buffer.putInt(intValue);/
>> /buffer.putLong(longValue);/
>> /buffer.flip();/
>> /
>> /
>> /Future writeFuture = connection.write(buffer);/
>> /writeFuture.get();/
>> here developer has full control over filling the buffer and
>> flushing it to network.
>> In Streams example:
>> /StreamWriter writer = connection.getStreamWriter();/
>> /writer.putInt(intValue);/
>> /writer.putLong(longValue);/
>> /
>
> I suspect writter.write(bb) or bytes is planned as well?
Yes.
>> /Future future = writer.flush();/
>> /future.get();/
>
> Same comment as above, e.g. CompletionHandler can probably be used
> here as well to avoid blocking.
Again, we can have several flush() versions.
>> we can not guarantee that flush operation will be called just once,
>> because internal buffer could be overflowed before flush() will be
>> explicitly called. Not sure this is a big deal, but just possible
>> issue.
>> I will appreciate feedback on API change proposal, and ideas, how
>> it could be improved.
>
> Looks promising!
Thanks.
WBR,
Alexey.
>
>
> A+
>
> -- Jeanfrancois
>
>> Thanks.
>> WBR,
>> Alexey.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>