[bind10-dev] Quality of in-memory code

[Michal 'vorner' Vaner]

Hello

As I had some trouble explaining my concern during the call yesterday, I'm
sending it in an email.

During the work on 2378, I decided to use the in-memory data source for some
testing. And I encountered several glitches:
 • The ZoneTableSegment has ::create and ::destroy. But the InMemoryClient
   accepts a shared_ptr to the zone table segment. That is incompatible.
 • The ZoneTableSegment::create takes a config argument, which is ignored. It
   wasn't made clear how it would look like or where would such config come from
   anyway. Is the user expected to configure some kind of segments by hand? I
   always thought there'd be option that would turn on the external memory
   manager and that'd be it.
 • The iterator has unimplemented getSOA(). What use is such iterator in
   practice and why is such a trivial method unimplemented in the first place?
 • The iterator was severely broken (fixed in #2378, since I needed it) ‒ it
   didn't include the NSEC3 namespace at all and it didn't include RRSIGs in
   separate_rrs mode.

However, my concern is _not_ about these concrete issues. I'll just create
tickets for them and they should be easy to fix. My concern is, this is quite
high amount of problems for the little part of the implementation I used.
Therefore I fear the quality of the in-memory implementation is lower than our
usual standard. I see several possibilities:
 • My memory is not good enough and there's always such high amount of problems.
 • We were in hurry with the implementation and the quality naturally reflected
   that.
 • There was some other problem with just this bit of code.
 • We are getting worse in the ability to design and write code. In other words,
   from now on, every new part of bind10 will have this amount of problems. This
   could be because people have little idea about the design before it is split
   single-handed into tasks and then are not consistent in how they think about
   the general idea (what happened to our plan about design calls and
   discussions?) or because there wasn't a f2f meeting for a while.
 • Something else?

With regards

-- 
Please enter password:

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20121128/033a980f/attachment.bin>