[bind10-dev] truncate, TCP, and UDPQuery (ticket #499 and #554) - please respond

[Scott Mann]

On 02/01/2011 06:21 AM, Shane Kerr wrote:
> Scott,
>
> On Mon, 2011-01-31 at 09:33 -0700, Scott Mann wrote:
>> The compromise solution is
>>
>> 3) abstract UDPQuery to IOFetch and add something (flag, union, etc) to
>> indicate whether tcp or udp ought to be used. Here, IOFetch would still
>> do much of the heavy lifting with respect to communication (setting up
>> socket and so on).
>>
>> It should be noted that there are other possibilities
>>
>> 4) Create a TCPFetch, which would behave similary to the current
>> UDPQuery, but use TCP. This approach seems heavy (redundant code).
> If we are able to modify IOFetch to such an extent that a flag can
> direct it to use either UDP or TCP, then surely we want to abstract out
> the UDP/TCP bits into a separate class and use them?

Yes. This would be the IOSocket implementation (it is a stub right now). 
I agree that that is what should be done.

> class IOFetchProtocol
> {
>      int connectThingy(...) = 0;
>       .
>       .
>       .
> }
>
> class IOFetch
> {
>      IOFetchProtocol fetch_protocol_;
>       .
>       .
>       .
> }

This works, too. Just for client connects? I think that's ok.

>> So, I sent out two emails over the weekend to bind10-dev largely to this
>> effect. Based on feedback from Jelte and some Jabber discussions, 3)
>> seemed the most reasonable approach. After some more Jabber discussions,
>> I opened ticket #554 for the abstraction of UDPQuery to IOFetch. I gave
>> it an estimate of "8", which may well be high. However, it will reduce
>> ticket #499 (the truncate problem) to a 2 or 3.
>>
>> The task described in 3), as I see it is:
>>
>> A) Convert UDPQuery from a struct to th IOFetch class (I think unions
>> inside the struct will be messy)
>> B) Implement TCP client-side support in IOFetch and remove the
>> dependency on UDP
>> C) Write unittests for TCP client-side support
>> D) Make sure that nothing that currently works gets broken.
>>
>> Let me know if I should stop work on these because we need to discuss
>> them at our next sprint.
> Does it make sense to split out A) into a separate task? Just in the
> interest of keeping things as small as possible...

Yes and include the additional abstraction you described above. A) is 
already ticket #554, which I gave an estimate of 8. Probably 5 is OK, 
though. I'm not yet writing C++ like prose, but I am getting there :)

So, now I have the separate ticket #554 for abstraction (to which I will 
add the protocol abstraction) and the previous ticket (499) for 
truncation. I am working on 554 and then I will do a review and then I 
will finish 499. Does that seem ok? Am I doing the proper things 
procedurally?

Thanks,
-Scott
> Otherwise I think the basic plan makes sense.
>
> --
> Shane
>