|
Ken,
I think you're hung up on the whole "hierarchy of a user maintained file structure." There's no need for the user to have any reason to create, organize, or maintain an actual file or directory structure. Hell, most people have no desire to do that, or in many cases the background or desire to understand the best ways to do so. In fact, there is no way to easily change the way you'd like to browse, so you're stuck with one hierarchy once you've implemented it.
The whole point of abstraction is to allow the machine to do the work for the user and present it however the user likes without having to change the most efficient underlying physical or logical structures employed by the file system and database. Let the database on the device take on the brunt of the work. The user only need dump books into one location for side loading and let the device take on the burden of organization.
This approach eliminates the need for any thrashing around every time the system is booted beyond checking one location for new books. Simple and FAST!
All tasks related to adding or dismissing titles, or even renaming them should be handled through the database.
I'm making the case that Kobo just hasn't gone far enough with their implementation of a database to eliminate the time-wasters and log jams.
You dump your stuff into the black box and let it do the heavy lifting. It's no big deal to allow an outside library like Calibre access and it might even make sense for the outside library to impose the file structure as long as it just dumps directories into "NEW" when adding items, or has another mechanism to remove them via the database. You do away with all duplicate processing or checking by passing everything through the database.
I think Kobo Development had a good idea, they have just not implemented it completely and this leaves holes for log jams to form.
|