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.
> 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?
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
>