>> I have directories on my filesystem(s), files in those directories
> Your library.
Yes, its already there and quite organized in directories. Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
>> powerful applications to navigate them (Total Commander / mc / Krusader).
> Not powerful enough. Filemanagers are optimized for hierachical views and don't integrate well with filetypes. Namely, they usually don't extract data from files, like metadata, covers or previews. Though, filemanagers have started to do that to some degree.
grep and find works quite well for most work loads and are fast, why not enhance (or fork) them to support ebook formats?
Instead ebook readers came along and reinvented filesystems, because users cannot be trusted to organize their book collection themselves.
> But they still lack the "alternate view" on your library. Those Walled Garden-Apps that work with librarys are more like a relational database, offering flexible selections and content-optimized views that filemanagers are normally lacking.
And at the same time omit very useful information that normal file managers show. (File creation/write/access time, size, full file name, etc.)
> The major difference is really just if you want a static and inflexible organization, or something dynamic. And usually with heterogeneous datas, the dynamic approach is better for consuming beacuse it allows you to break through the hierachy.
As I said, with long indexing times. I had ~50000 books on a ebook reader once and that broke it. Just because there are files stored, that should not slow down the system or even make it completely unusable.
Instead they should just access the filesystem directly, then those problems don't even arise.
>> (eg. where do I find all those books when I want to copy them?). > I hate Calibre for the exact same reason.
> Just select your books and export them. Calibre can export to a device, but also just a local directory. Calibre in that regard is one of the better gardens. Very flexible and powerful. Just the UI sucks.
Calibre is a pretty big application and they are not an ebook reader primarily. Their main feature is the library. And they spend many man years of development to improve that and it does work quite well.
But very few ebook applications and handheld readers have the same resources to implement a similarly powerful library functionality. Instead they have half backed solutions that make finding and organizing the library more difficult then if they would have simply used a standard file manager and grep/find/...
IMO an application that lets you just open epubs and other ebook formats and render them correctly just like so many pdf viewer do, without any half assed library functionality duck taped on to it, is highly sought after.
I agree with your point about the library. Maybe I'm just weird, but typically I'll read one, MAYBE two books at a time before moving on to another. Because of this, I really don't need the app to show me my library like this every time because its not like I'll be hopping around between books several times within an hour. I can see how this library setup makes sense for a music player or some sort of gaming platform, but it feels like for books they're just bringing the feature along without considering whether or not it makes sense. I guess it is nice to be able to gaze upon your library and think "wow I've read a lot" or "wow I have a lot of options to read", but I"m not sure I'd say that's worth the start up time.
>Instead ebook readers came along and reinvented filesystems, because users cannot be trusted to organize their book collection themselves.
In the early days of Mac OSX, iTunes actually did a great job of just organizing your music collection for you. It would sort your music into a nested hierarchy by artist, album, and track title based on the metadata on the file, which you could edit with iTunes. When you changed stuff around it would actually modify where the files were saved in the library folder.
It worked great. It was structured logically in your iTunes library, but organizing and tagging your iTunes library also wound up structuring your file system logically automatically. So there was never this sense of a pretty veneer over a messy clusterfuck underneath. The whole thing is designed to keep things tidy and organized.
> Yes, its already there and quite organized in directories.
So you do understand the general concept of a library. Then you also understand the limitations of directories and how much work goes in maintaining this system.
> Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
I don't think Ebook-readers started this. ITunes had this first I think, or whatever app ITunes copied from back then.
> grep and find works quite well for most work loads and are fast, why not enhance (or fork) them to support ebook formats?
Doesn't solve the problem. Grep and find don't give a useful interface for elaborated tasks. They also don't support metadata which are not supported by a fileformat, meaning "external" metadata.
> And at the same time omit very useful information that normal file managers show. (File creation/write/access time, size, full file name, etc.)
Depends on the application, and the user. Not all of those information are useful for everyone. Calibre for example has good support for filemanagers. Each entry has a link to open the folder with the ebooks. The whole library is saved as a folder-hierachy with metadate extrated into seperate files. The Database-View is just an additional layer.
> As I said, with long indexing times. I had ~50000 books on a ebook reader once and that broke it. Just because there are files stored, that should not slow down the system or even make it completely unusable.
Indexing is a neccessary tradeoff for gaining power. The alternative would be to constantly scan all files, making every single task slower. grep and find have their price too.
> But very few ebook applications and handheld readers have the same resources to implement a similarly powerful library functionality. Instead they have half backed solutions that make finding and organizing the library more difficult then if they would have simply used a standard file manager and grep/find/...
Oh yeah, I guess grep on an eReader would be a real pleasure to use...
> IMO an application that lets you just open epubs and other ebook formats and render them correctly just like so many pdf viewer do, without any half assed library functionality duck taped on to it, is highly sought after.
Those applications exist. Calibre even comes with one out of the box. Not their fault if you just start the library and not the reader.
I am not against an index or library in addition to the file hierarchy, but I am against a library or index replacing a directory listing.
Both perspectives are very valuable!
Also a full text search (grep) or (more or less simple) file search (find) are useful in addition to a library.
To reiterate, for me it seems that itunes and ebook reader generation of devices and applications don't seem to value custom directory organization.
> Those applications exist. Calibre even comes with one out of the box. Not their fault if you just start the library and not the reader.
While the library part of calibre is very good, the reader part is not so great, but that just might be because a library application is much more difficult to implement than the reader, so bad UI can be looked over there, but not in the reader. Otherwise I agree that this the application of choice for reading ebooks on Linux desktop.
I am honestly very curious about what file structure you use for your ebooks. After 500 or so, I threw up my hands and just wrote some Perl scripts to flatten the filenames into something meaningful, and threw them into a big git-annex repository.
I have at least two dimensions I'm dealing with: title, and file type. Really though, it's nice to also organize by genre, and year.
I also dislike most of these walled garden library apps, and they are usually poorly written and obtuse. I would love an app that can scan my existing ebook repo, and then also create an index database, and make the books available on my mobile device.
One pattern for sharing my rigidly structured data from my desktop to my iPad, is to just share my working tree over Dropbox, because I use git-annex for my file collections. That way, I have automatic syncing of the files, but also the safety of snapshots. If I do want to incorporate a change I make on a mobile device, I can simply make a commit on my desktop, but if some poorly written app decides to start screwing with my metadata, I can re-check the files out. OSX Preview.app is infamous for this.
I use syncthing for file syncronization between laptop, desktop, nas and mobile phone.
And scripts that 'index' the books and create a directory structure of the metadata (like tags, series, publication date etc.) containing symlinks to the real books.
>To reiterate, for me it seems that itunes and ebook reader generation of devices and applications don't seem to value custom directory organization.
Do you primarily or only use one computer or one os?
I'm on 3 different OSes regularly, over 5 different computers counting ones at work. For me, the effort to setup custom directory organization is a complete waste of time unless structure and tags can easily travel between computers, filesystems, and OSes.
Letting the app (Calibre for books, Mendeley Desktop for pdf's) organize however it wants lets me just clone the directory and preserve tags, which is actually what is important to me (or in the case of Mendeley, log in and sync documents/tags). I'm not a music listener at work or I'd just let an app organize that too if it syncs my tags.
> To reiterate, for me it seems that itunes and ebook reader generation of devices and applications don't seem to value custom directory organization.
Yes, because it's expensive and has little value for the user. A guided application, streamlinend for well defined purpose is always simpler to create and cheaper to maintain. There is a reason why free software is usually more open for user-custimization.
> While the library part of calibre is very good, the reader part is not so great
Indeed. I thinks it's mainly because calibre is mostly used for feeding devices and maintaining and manipulating the library, less for actual reading books on desktop-PCs.
At the very least you need the title and author metadata. This can be done in the filesytem, but it's unweildy. I use Fbreader and run a Calibre server to manage my collection and epub metadata.
Fbreader lets me browse the filesystem, or search by different metadata.
>>> I have directories on my filesystem(s), files in those directories
>> Your library.
> Yes, its already there and quite organized in directories. Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
This has been a complaint of mine with music programs for, literally I think, decades. If you need to overlay some metadata that's fine, but in that case at least index it by header checksums or something, not by file names and paths! (Especially not absolute paths.) Please respect my organizational choices and make sure I can rename and move things around without worrying about "ruining" the database.
> Your library.
Yes, its already there and quite organized in directories. Now ebook readers came along and pressed those hierarchical data flat, with long waiting times, because it needs to index first.
>> powerful applications to navigate them (Total Commander / mc / Krusader).
> Not powerful enough. Filemanagers are optimized for hierachical views and don't integrate well with filetypes. Namely, they usually don't extract data from files, like metadata, covers or previews. Though, filemanagers have started to do that to some degree.
grep and find works quite well for most work loads and are fast, why not enhance (or fork) them to support ebook formats?
Instead ebook readers came along and reinvented filesystems, because users cannot be trusted to organize their book collection themselves.
> But they still lack the "alternate view" on your library. Those Walled Garden-Apps that work with librarys are more like a relational database, offering flexible selections and content-optimized views that filemanagers are normally lacking.
And at the same time omit very useful information that normal file managers show. (File creation/write/access time, size, full file name, etc.)
> The major difference is really just if you want a static and inflexible organization, or something dynamic. And usually with heterogeneous datas, the dynamic approach is better for consuming beacuse it allows you to break through the hierachy.
As I said, with long indexing times. I had ~50000 books on a ebook reader once and that broke it. Just because there are files stored, that should not slow down the system or even make it completely unusable.
Instead they should just access the filesystem directly, then those problems don't even arise.
>> (eg. where do I find all those books when I want to copy them?). > I hate Calibre for the exact same reason.
> Just select your books and export them. Calibre can export to a device, but also just a local directory. Calibre in that regard is one of the better gardens. Very flexible and powerful. Just the UI sucks.
Calibre is a pretty big application and they are not an ebook reader primarily. Their main feature is the library. And they spend many man years of development to improve that and it does work quite well.
But very few ebook applications and handheld readers have the same resources to implement a similarly powerful library functionality. Instead they have half backed solutions that make finding and organizing the library more difficult then if they would have simply used a standard file manager and grep/find/...
IMO an application that lets you just open epubs and other ebook formats and render them correctly just like so many pdf viewer do, without any half assed library functionality duck taped on to it, is highly sought after.