Hello Douglas, I suppose my own development experience with the Palm has biased my opinion on how the platform is typically used. For example, I've never thought that features like unique IDs and record attributes were worth the bother of using them, and most of the Palm databases I work with use fixed length records for the main data. Where possible, I store string data in a separate database, in a more relational database fashion. We'd have to conduct a survey to determine whether the average Palm developer uses fixed length records or not, but either way, my assumption was probably unfounded.
The thing that confuses me is that it seems you are advocating against the use of a logical record scheme. Waiting for 10,000+ records to HotSync is not a very pleasant experience, and currently having such a large number of records will cause an application to simply not work on the new PalmOne devices. Are you trying to say that Palm (One/Source) should not do something to help developers work around this problem? Notwithstanding the current problems with the T5 and Treo 650, I still have to wonder why a library hasn't been developed to make this process simpler ages ago. Adrien. Wednesday, May 11, 2005, 9:45:43 AM, you wrote: DH> 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. DH> I suspect that would cover relatively few cases -- even if not "packing" records DH> by eliminating unused fields as the original PIM databases do, having variable DH> length strings is extremely common. The net result is I believe you would find DH> the vast majority of pdb's consist of variable length records. So the developer DH> would have to set the logical record size to the maximum possible length if the DH> wrapper were to assume consistent sizes, and that could negate any benefit. DH> In fact, if the record contains any memo-like fields, a given record may easily DH> exceed the NVFS block size (512 on the T5) even if typical records were under DH> say 64 bytes or whatever. DH> I don't believe such a simplistic approach would achieve much real world DH> 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. DH> No, the bigger challenge would be compatibility with conduits and code which DH> relies on record attributes, categories, unique IDs, etc. Not to mention the DH> ramifications on memory handle operations and Exchange Manager functions. It DH> isn't just the Dm...() calls which would be impacted with such a wrapper. DH> Besides, the whole point of using the block size seems to be avoiding the DH> performance penalty of having to read/write all other record(s) which happen to DH> be at least partially within that memory block. And by implementing such a DH> wrapper you are already causing write operations to include the other logical DH> records within the same physical record. DH> Then consider the ramifications for things like DH> DmMoveRecord() used when sorting DH> databases, or record insertions or deletions. DH> Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
