On 28 August 2014 18:34, Thiago Macieira <[email protected]> wrote: > On Thursday 28 August 2014 14:18:06 Rutledge Shawn wrote: >> > I want an API that makes it clear that detection may fail or be >> > ambiguous. >> > Call it "storage locality" or "storage remoteness" or, hopefully, some >> > better name. >> > >> > The more types we start to add, the more difficult it becomes. We can >> > provide an extra attribute for those types that are determined to be >> > local to report whether they're fixed, removable, virtual or unknown. >> >> There could be a hybrid (maybe it's even common already… I'm not a user of >> commercial cloud storage yet so don't know): cloud storage with a big local >> cache, so that many files are available offline, but not everything. In >> the database use case maybe it should be considered local, because >> performance will be OK, but it's not strictly true. > > That's a good point and worth the fourth state. > > Some applications may accept using it because it's fast. Some others may > refuse because huge amounts of data might be uploaded to the cloud. I wouldn't > want a constantly-changing database getting sync'ed. > > That said, I can't fathom a way of detecting this in any current system, with > any API.
My point was that with flags, they can be ORed together... just in case. It's better than reserving a fourth state I think. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
