>
>> Hi,
>>>> IMHO boolean looks bad.
>>>> write(buffer, true) vs. writeAsync(buffer)
>>>> I will prefer 2nd ;)
>>> I think both opinions have their pros and cons but
>>> in the moment I prefer Jeanfrancois's approach.
>>>
>>> It's because I just prefer the shorter API and so just want to
>>> memorize
>>> two methods. So I would handle async and blocking with
>>> ReadFuture read(buffer,blockingBoolean,CompetionHandler,nowBoolean)
>> well, for blocking mode returning ReadFuture and parameter
>> completionHandler don't have any sense.
>
> No it makes sense. When blocking doesn't have bytes to read, it
> block. Having A Future to stop the blocking thread because there is
> no more bytes available would be usefull. Right now we don't have /
> cannot control that issue, and sometimes all threads end up blocked.
> Hence Future would help :-)
While operation is blocking you can not get Future ;)
>>> maybe I don't care about the inconvience
>>> when using blocking calls because
>>> I always try to go the async way(-:
>> Hmm. May be it could make sense to remove blocking read/write at
>> all, so blocking I/O operations will be accessible just via:
>> TemporarySelectorIO.write(Connection, Buffer).
>> and read/write methods will work just in async mode.
>> What do you think?
>
> I'm still in favor of read(bb), read(bb, true/false) ...same for
> write. Having to use another object for doing read/write will just
> complexify the design (like we have right n ow in 1.x). A unify
> interface will be better IMO :-)
Once we need to return different objects as result of blocking and
async I/O operations (Future and Result)... I don't see the ways how
we can unify this.
WBR,
Alexey.
>
>
> A+
>
> -- Jeanfrancois
>
>
>> Thanks.
>> WBR,
>> Alexey.
>>>
>>>
>>>
>>>> Salut,
>>>>
>>>> Alexey and I are having fun here:
>>>>
>>>> http://www.nabble.com/Grizzly-2.0%3A-Standalone-filterchain-processing-example-td19612479.html
>>>>
>>>> we don't agree and it would be quite nice to have at least another
>>>> commiter to jump and tell us what he thinks.
>>>>
>>>> This is great work anyway :-)
>>>>
>>>> A+
>>>>
>>>> --Jeanfranmcois
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>> --
>>> GMX startet ShortView.de. Hier findest Du Leute mit Deinen
>>> Interessen!
>>> Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
>>>
>>> ---------------------------------------------------------------------
>>> 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
>