|
TechniSol;
I agree on the concept you are describing, and we could certainly "have both" but I think you are underestimating both what is accomplished in indexing and in the process of building a menu listing of files.
In concept; the SQL database provides an abstraction of the file system, long one of the original goals of a "true" Operating system. If Kobo had it implemented to the potential of the concept, what would appear to the user as "a full blown file browser" would be the simplest of things to provide. The actual file structure, management and initial construction, would be irrelevant. (That being the point of the abstraction.) Please note that this argument works both ways, an efficient user managed file structure would not be an obstacle to the SQL based features.
Menu Browsing is part of the current FW, you browse search results, you browse the shelves. Providing the ability to browse a hierarchical menu of the files couldn't be that big an issue, except for Kobo's design philosophy.
You seem to see a demanding "need to scour the file system each time it was started up" as something that isn't needed with the existence of the SQL database, but in reality the OS needs to do much of what I presume you are referring to, with or without an SQL database in the mix. Some of what you may be referring to takes place in the menu building process often on a page by page basis, not all at one time, for all the files in the file structure.
I keep getting back to the fact that other much less powerful ereading devices have no problem dealing quickly and efficiently with large file structures, using the simple file browsing approach. But as you mention the database book sorting should be superior to a simple file menu browsing approach. I am encouraged that there is some evidence that Kobo is improving the file processing. Maybe it will get to the point that it functions as well as the other ereaders out there. But, as far as the adding the ability to browse the file structure, they could add that any time.
Luck;
Ken
|