BIND 10 #404: serialize RDATA for in memory data source

[BIND 10 Development]

#404: serialize RDATA for in memory data source
-------------------------------------+-------------------------------------
                 Reporter:  jinmei   |                Owner:  jinmei
                     Type:  task     |               Status:  reviewing
                 Priority:  major    |            Milestone:
                Component:  data     |  Sprint-20110419
  source                             |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  0.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:21 jinmei]:
 > I'm happy to raise this project wise, but I'm a bit pessimistic we can
 > have a consensus.  For this specific case, as you seem to want to
 > avoid hiding buffer quite strongly, and as I have to admit it wouldn't
 > be very convincing to insist on this case while leaving many others,
 > I'm okay with leaving the decision on this point to you.

 OK, I sent a mail to the dev list, let's at last try and wait a little
 bit. This task isn't in any real hurry anyway.

 > > So I'm little bit reluctant to do that. Is it about the binary
 compatibility as well?
 >
 > Yes, that's the same discussion.  I simply repeated it as a summarized
 > specific point to the branch code itself.  See above.

 OK, so I'm leaving this open for now.

 > My main concern in this context is to ensure the (larger) flexibility
 > of changing the internal representation before many other clients,
 > hopefully third party ones, relies on the public interfaces.  Once
 > someone starts relying on the fact that the backend of MessageRenderer
 > is OutputBuffer, we won't be able to change that without breaking
 > compatibility of that deployment.  It's true that it's not a problem
 > today, and, if we are lucky (or unlucky that no one else is interested
 > in using our APIs) this may never be an issue in future.  But exactly
 > because it's not an immediate threat we tend to underestimate the
 > risk, and will only regret the decision when the risk is realized and
 > it's too late.

 Hmm, I see, I didn't think about this issue. Yes, it makes sense, I tried
 to hide it inside. But I still had to provide the getBuffer() method,
 because the MessageRenderer needs to store references to them from time to
 time. It could be refactored so it wouldn't need it, but it seemed too big
 change inside this ticket. Should I create a ticket for it?

 > > Anyway, could I propose that we take the lazy approach, make a
 > > ticket or comment at the interface and leave it as it is until the
 > > change brings any advantage?
 >
 > That's fine.  In general I agree we should limit the scope of
 > individual tickets.

 I put a doxygen todo at the interface.

 > > So I might return it back to `void *`. However, thinking about it, why
 we returned  `void *` in the first place, when the docs say it can be
 type-casted to `FieldSpec`? In that sense, the API seems inconsistent,
 since `void *` usually describe „typeless unknown data“. Wouldn't
 returning a `FieldSpec *` make more sense?
 >
 > Hmm, good point.  I don't remember what I exactly thought about the
 > interface consistency when I first wrote the original code, but my
 > general intent is to treat the exposed data as opaque as possible.
 > So, if it doesn't break other part, it will probably make more sense
 > to change the second constructor of RdataFields so that it takes void*
 > instead of FieldSpec* (and internally convert it to FieldSpec* using
 > cast).  And, in that case, it may also make sense to use the actual
 > data length rather than the number of spec's.

 I changed it to void* and the field length function to return number of
 bytes. I also changed the getData to return void* and the constructor to
 take void* pointers to make it little bit more consistent and noted that
 it isn't actually expected that users would like to dig trough the data.

 I hope I didn't forget anything.

 With regards

-- 
Ticket URL: <http://bind10.isc.org/ticket/404#comment:23>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development