Several tag data types have never been used (RPM_CHAR_TYPE),
or implemented (RPM_NULL_TYPE), and are headed for the bit bucket.
At the same time, I'm likely going to add implicit typing of existing
tags
using the autogenerated triples {"name", number, type} entries in
rpmdb/tagtbl.c,
none of the tag data types have changed in years. I'll add an assertion
to insure that the table agrees with the rpm code for a week or so
before removing.
At that point, rpm-5.0 is well positioned for doing type coercion, as
well as
adding support for new/arbitrary tag data types. Any additional types
will
be coerced into RPM_BIN_TYPE within a *.rpm for legacy compatibility.
Any suggestions for other new data types?
On my short list are:
1) Adding a associative array data ttype.
rpm already has RPM_I18NSTRING_TYPE as an associative array, but
the implementation is so arcane it hurts.
Basically, two tag arrays are associated, the first as index,
the second
as value. A one-of-N lookup proceeds by finding the key in the
index tag,
and returning same entry from the value tag.
As currently implemented in RPM_I18NSTRING_TYPE, locale is used as
implicit key, and both the index and value tags are strings. The
generalization
is rather obvious.
2) Adding hex/base64 transforms.
Headers cannot currently represent an array of variable length
octets. Converting
to hex or base64 encoding solves the representation problem
(there's still the
issue of how to pass octet lengths).
3) Dictionary lookup.
For compactness, some strings are uniqified in one tag array,
and then indexed
from another tag array. The technique is quite powerful and
leads to overall reduction
of redundant content.
4) Well formedness constraints on values.
Certain tags have additional well-formedness constraints, like
parseable
as hex, or composed of RFC-2440 packates, that cannot currently
be tested
because the goop is just dumped into RPM_BIN_TYPE octets.
73 de Jeff
Received on Wed Nov 7 15:36:12 2007