Salut,
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.
>>
>> 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 ;)
Indeed :-) LOL! I would still return a Future that contains the
ReadResult etc and the number of bytes written.
>
>
>>>> 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.
>
Hum...I do think we need to unify. Why? NIO.2 will also soon comes into
the picture. Let's discuss at the meeting today.
A+
- jeanfrancois
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>