Hm, I thought originally you thought that all attributes should get time stamps.
I did, but I'm having trouble justifying the cost or imagining a value not already covered by just tracking timestamps per object.
1. Are attributes to be time stamped? If so, and we use
key=binaryattribute-timestamp, we get a lot of overhead space taken up
with the keys.
We could calculate the over for a couple examples, but intuitively I could see this doubling the size of a .g file.
2. If objects only are to be time stamped, will that be in the object
body or in a separate object again with key=binaryattribute-timestamp
(and more space overhead for keys).
I guess I need more on your ideas for binary attribute implementation.
Is that more clear? Basically my idea was that we'd store the timestamps on objects directly as attributes. We modify attribute reading/writing to support binary attributes (will have to be very careful, must be backwards-compatible). We implement/fix LIBBU support for timestamping (currently Windows is inconsistent). We make all database object I/O go through standard routines, so we can ensure the stamps are correctly handled. Then commands get updated to use this information (e.g., list recently/last changed objects).
We need some means to discuss and mark-up beyond comments in the xml. Suggestions? The spec used to exist as a word doc with reviewer comments. Docbook is rather limited in that capacity.
For sure. I guess we could put it back into MS Word format, but
looks-wise that would be a downgrade.
As a trial, I suggest someone convert the db5 spec to asciidoc (would be a good GCI task) since it's supposed to be faithful to Docbook (unlike markdown, it's a subset). It actually uses Docbook under the hood, so it should be a really good fit. Asciidoc has built-in support for editorial comments that are suppressed by default, so it can also just stay in svn as a text document and we can comment directly there.
Cheers!
Sean
------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
