Would it make sense to talk about this at the Grizzly Project meeting
(which is open to the entire Grizzly community)?
Reason I suggest the Grizzly Project meeting is .... Ken is almost
always available for that meeting and given Ken's vast experience with
API development, I think hearing his perspective would be very valuable.
charlie ...
Oleksiy Stashok wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
<http://java.sun.com/docs/performance/>