[bind10-dev] flaws in reversed name-based approach for getting the "previous name"

[Stephen Morris]

On 04/10/2011 19:08, JINMEI Tatuya / 神明達哉 wrote:
> At Mon, 26 Sep 2011 12:32:17 -0700, JINMEI Tatuya <jinmei at isc.org>
> wrote:

> According to today's biweekly call, the consensus seems we should 
> address this issue.  In that case I personally think Shane's
> proposal is simple and effective enough.  Stephen mentioned some
> possible alternatives in the call, but I didn't fully understand
> them at that time, much less whether they are better than Shane's.
> If think they are better, could you explain your ideas again here?
> > Stephen

There were several ideas:

First, internally we should encode the \nnn format characters as
single bytes in the domain name.  The conversion between internal
representation and \nnn should be done on input and output -
internally we should not have to worry about them.

For the "-" v "." problem, we should be able to alter the collating
function used by sort functions.  In Sqlite3, the collation function
can be set by the sqlite3_create_collationXxx  functions.  In-memory
sorts generally require a comparison function.

Finally, the problem of \046 (the period) within a label could be
handled by associating the name with another structure holding the
location of these characters within the name.  The structure is
created when the name is converted to the internal string and used
when rendering the name into readable format.

> Some other related notes: - The consensus on the slightly related
> issue of whether to allow non-captive mode seemed that we should
> allow it, at least for some backends.  But as I said in my other
> message in this thread, I personally don't think that affects the
> solution to this problem (if someone disagrees please speak up)

The fact that there are two representations of the data would seem to
suggest a captive SQL database. I would suggest that we store both
both the internal and external  representation of the data in the
database as that would make it easier for applications that just want
to read the data. (Although if we do that, we would need some form of
check/repair utility to ensure that the two representations remain in
sync.)

(If it SQLite had stored procedures we could name the database
non-captive - have a stored procedure update the internal
representation every time the external one was changed.
Unfortunately, it doesn't, although some work has been done in this
area - see
http://chriswolf.heroku.com/articles/2011/01/26/adding-stored-procedures-to-sqlite)

Stephen