Sorry, for the length of this response. I had to leave for my son's birthday. I would have liked to have been in the thick of this. After all, I started it :)
> I have a theory that it's a little more complex than that. I think > what happened is that the T5 was supposed to be an OS 6 device, but > PalmOne punted at or near the last minute and decided to make it an > OS 5 device. Whether this was due to PalmOne's unwillingness to Thanks Logan, but from the developer and user's perspective, it doesn't matter what predicament they (PalmX) faced, or that they didn't "intend" to break anything. What's important is that they knowingly DID depart from some very important things and broke several other things. >>(with battery backed) You reset and you've lost nothing. The new way >>buffers all our nice >>important data in volatile storage. We can't flush it and we can't >>know when the OS has deigned to write it through to flash, so we never >>really know when the data is safe. Scratch reliability. >Wrong! While we can't "flush" the cache and *empty* it, we can force >the cache to be committed back to NAND and therefore be safe from loss. >But then with your attitude of "Forget the white paper", I guess you'll >never read about adding calls to DmSyncDatabase() to force this commit >to occur. Thanks Doug, but many of you still consider manipulating a single record and then syncing it, the only kind of database activity used. Our app requires a fairly complex data caching scheme. It requires simultaneous use and update of tens of megabytes of data. The NAND flash and device performance in general cannot tolerate constantly syncing each database every time a cache link or update is performed. We'd quickly wear out the flash, our patience or both. My attitude is not the question - I've read the white paper. It doesn't address complicated apps. It gives simplistic bandaids for general purpose use. It does not address our issues. >I don't have any problems with realiability in my tests, even with >unannounced resets. But then, I read the white paper... Please lay off the white paper. Some apps can accept simple workarounds. Your issues may have been resolved, but ours remain. We use NetLib over the cell phone on the Treo650. That's bad enough on any device. It's even worse on Palm devices. Resets are simply a fact of life. Until NVFS, we could endure them. Now, however... >I'm planning on doing a talk on NVFS at PalmSource 2005; I'm still >gathering all my information and seeing just what I can get cleared by >legal, but I hope to have a lot of information about the initial >implementation, the changes made for the Sprint Treo 650 update, and, if I >can, future directions for this technology. I appreciate you in the forum Ben, and I'll look forward to your presentation, but I'm afraid I'm less interested in the history and good intentions of NVFS, than I am hearing how it will be fixed. >For those of us who can't make the conference, I would presentation materials or >a white paper or something will be released following the conference. Ditto. >IMHO I don't think data loss is a real threat for most users and I don't >think flash memory is better and more reliable than it's counterpart. I agree Miguel. Even if the NVFS implementation worked reliably, it only solves lesser problems. It cannot be argued that it provides better, or even the same data reliability during use, only that it doesn't forget what you can manage to stuff into it before the platform croaks out from under you. >I for one >feel that non-volatile memory is one of the most important additions to >the handheld world in a long time. That said, I can't speak to how well >it's been implemented on the T5 and Treo 650, because I haven't used >either device yet. The battery on my Simulator works great though... :) I have no problem with non volatile storage Mark, only as you say, the implementation. If they couldn't get it right, they could have made it a built in SD card, and left the storage heap in battery backed ram. At least then it would be up to us how we choose to impose "reliability". >I think you may be underestimating the significance of non-volatile memory. And >keep in mind that one real advantage is the T5 does not require *any* battery >power while "off". So it can sit in a drawer or purse for whatever length of >time, and when you pull it out it is still ready to go. This may encourage >people who don't use it as often, to start using it more and/or perceive it as >more reliable. Please see my offhanded interim solution in the previous paragragh, Doug. You don't have to throw out the value of non volatile. The same can be accomplished in any previous device that supported an SD card. They didn't have to complicate our lives with a poorly implemented and MANDATORY NVFS. >I'm not saying non-volatile memory is less or not reliable but what I >think is that many times the phrase "you won't lose your data" is >misused to improve the perceived reliability, and perceived != real. Yes, Miguel, probably the core of my frustration. It's pretty obvious at a glance the problems NVFS brings to the table, yet PalmX decided to do it anyway. That just burns me up. Thanks to all who read through this. I get long winded. It sounds like I'm the great curmudgeon I'm often accused of being, but I'm really a nice guy, albeit frustrated. All of you guys keep up the good work. You too, PalmX. jeff -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
