Adrien, >Of course, I'm assuming that the logical records would be the same >size for the above implementation, but that would likely cover the >majority of developer cases already.
I suspect that would cover relatively few cases -- even if not "packing" records by eliminating unused fields as the original PIM databases do, having variable length strings is extremely common. The net result is I believe you would find the vast majority of pdb's consist of variable length records. So the developer would have to set the logical record size to the maximum possible length if the wrapper were to assume consistent sizes, and that could negate any benefit. In fact, if the record contains any memo-like fields, a given record may easily exceed the NVFS block size (512 on the T5) even if typical records were under say 64 bytes or whatever. I don't believe such a simplistic approach would achieve much real world benefits, even if it didn't introduce new compatibility problems. >If for some reason it's not practical to modify the original Dm family >of functions easily, a total wrapper around the DataMgr shouldn't be >too difficult. The biggest challenge would likely be the typing >element rather than any complexity in actually developing it. No, the bigger challenge would be compatibility with conduits and code which relies on record attributes, categories, unique IDs, etc. Not to mention the ramifications on memory handle operations and Exchange Manager functions. It isn't just the Dm...() calls which would be impacted with such a wrapper. Besides, the whole point of using the block size seems to be avoiding the performance penalty of having to read/write all other record(s) which happen to be at least partially within that memory block. And by implementing such a wrapper you are already causing write operations to include the other logical records within the same physical record. Then consider the ramifications for things like DmMoveRecord() used when sorting databases, or record insertions or deletions. Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
