On Oct 28, 2013, at 6:53 AM, Tom Browder wrote: > (Note that I I think it is better not to mix > time stamps with attributes.)
Not sure I understand this. If you're saying that we should not time stamp attributes themselves, I agree. If you're saying we should not store time stamps as attributes, I might need some convincing. > 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]). This would be a great project for anyone interested in getting involved on a more serious level. It's an isolated feature. It's very low-level. Lots of design possibilities. > 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.) Except those flags are exactly the mechanism that will allow us to embed binary data that was previously unanticipated. Instead of compression, think of them as "encoding" flags. I still need to go through the specification in detail, but my quick re-review a month or so ago indicated that was the perfect place to inject support for binary attributes. They're needed for the parametric constraint system, dimensioning, and would be ideal for timestamping. > Back to the subject of time stamps: we could let the user decide > whether to use them or not. I don't see a need or value for providing them optionally considering the implementation should have nominal disk and CPU implications. If it has more, we probably haven't thought about it hard enough or implemented it well enough. > If the time stamp proposals in the draft DB V5 document look okay, I > can start back working on them. 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. Cheers! Sean ------------------------------------------------------------------------------ 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
