On Thu, Aug 29, 2013 at 8:07 PM, Christopher Sean Morrison <[email protected]> wrote: ... > Sounds quite reasonable to me. It fits the object data model best (as it is > metadata) to store them in the database record as a set of attributes, > ideally as binary int64 values but that's a problem we'll have to sort out.
I have been working on getting the DB V5 doc in better shape so it will eventually reflect the current state of the DB exactly. While in it I took the liberty of adding a proposed DB format change to include the object time stamps. (Note that I I think it is better not to mix time stamps with attributes.) While on the subject of the database I was thinking that we need some kind of DB analysis and management program (I think such is in the TODO somewhere). One of the things it could do is rewrite a DB to eliminate holes which real users would like. Often g2asc/asc2g is abused for that purpose so it would be very useful. (Note that another reason users use asc2g is for textual version control--not very useful unless the DB is rewritten into some canonical order beforehand [or during the conversion]). Also, we may consider whether to eliminate DB internal compression to free up some flags--I suspect the overhead is not worth carrying the Z flags since there are so many external compressors that would probably do at least as well as a built-in compressor. (But, on the other hand, transparent compression is a nice feature, too.) Back to the subject of time stamps: we could let the user decide whether to use them or not. If the time stamp proposals in the draft DB V5 document look okay, I can start back working on them. Best regards, -Tom ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
