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

[Shane Kerr]

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?

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

class IOFetch 
{
    IOFetchProtocol fetch_protocol_;
     .
     .
     .
}

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

Otherwise I think the basic plan makes sense.

--
Shane