Online streaming, nfs, samba, calibre web (https://github.com/janeczku/calibre-web)

[i30817]

I'd like to access my ebook\comics collection from a home server, much like VLC can for music. But better (I noticed vlc can't access files with a '?' on them - note on nfs not smb\samba, since I have a linux server and android device, and samba filenames are even worse. This bug is likely because vlc used a URI\url library to encode nfs paths then screwed up ? because it's also used as a query marker in uri\urls).

Adding remote capability to apps like this is unfortunately required to be handled by the app itself since android\google hates people having their own remote services, and do nothing to help it with the default filechooser... ebook\comics readers with nfs service are nonexistent probably because they want to 'support' windows with online hosting and forget about nfs (much faster, no filename limitations... not windows compatible), they're mostly all samba. It's irritating to rename files and recreate playlists just to appease windows, which I do not have.

Anyway, the calibre web protocol, OPDS, is probably better. There also is a extension to send back pages read to the server and one to transfer only a single page at a time, although I'm pretty sure they're not implemented in calibre-web unfortunately (here is the bug report for the second https://github.com/janeczku/calibre-web/issues/804)

[pjz]

Add my vote to support OPDS ; it's an open spec that's not specific to one software package, and many readers already support it. My favorite OPDS server is kavita, which does have web readers... but is fairly impractical on a phone-sized device.

As for UI suggestions: either add an 'from OPDS Library' to the Import menu, or add a 'Network Library' button at the bottom that would let you add/remove/browse your network libraries, and choose what to download and import.

[i30817]

One problem of opds is that it doesn't support covers without a nonstandard extension I forget and that is rarely implemented in opds servers. A second is that I've never seen a OPDS implementation that ended up as a nice gui, like a searchable single bookshelf, it's always a html options list leading to a pagined gui each where you can't see all books at once much less find the one you want with a few single keystrokes (some do have a search but as far as I know, not a with the option\text input for a tag search, or 'find other books in the series (ordered) or find other books by author (series ordered and borders of series visible in the gui)').

I never implemented a OPDS consumer or read the spec, but all of the gui experience of apps that do being so similar makes me think this is because the spec mandates a number of standard text\html responses, all based in pagination to not transfer over a lot of data, which is insufficient without further work and latency to stuff in a seamless shelf gui as "all books". It's probably very possible to do so by using a html tree parser like beautifulsoup and a epub\mobi extractor to get the cover, book relationships and topics lists. People just don't.

Btw a way to work around lack of remote storage support in some apps that use the default file chooser and don't copy files to the local storage (unfortunately unlike most screen readers), is to use https://github.com/chenxiaolong/RSAF and some Linux server of one of the possible backends (I use webdav).

It doesn't work well for most screen readers because they either don't use the native filechooser\don't have a way to handle SAF files, or the other unrelated reason that they want to control the library directory in local storage and copy files over (turning the idea of seamless remote storage useless), or more strange, don't support directory hiearchies.

Unfortunately SAF and RSAF even more, are slow. Wouldn't matter too much for books though.

[i30817]

In short, I think all user interfaces of book lists in ebook readers, not just OPDS ones or calibre web clients are all fairly user not hostile, but annoying to use.

Ideally my ideal interface would have:

1. 1 single visual shelf (when possible lazy load cover\the gui entity representation of the book, but have all the data available for later user options) representation of books.
2. that you can reorder from a mix of last read ordering, to last modified, to last inserted (default and for non obvious reasons not quite the filesystem walk it could be implemented as), to series ordering (for cases where multiple main authors do a shared series), to publish-date-by-author order, and for all these orders changing the ordering keeps and centers the selected book (so you don't have to look for it again). Moreover these orderings would have a ordering such that a user searching by series then author would get authors ordered inside by series (a well known property of some sorting algorithms) even better, the base default sorting (last inserted) being built in such a way that the books are already inserted by ordered author and inside by series (when possible), which can be done with a priority queue for series sort, then a final sort by author, or just two sorts after having all the data.
3. that you can further restrict with a single search bar with intelligent auto complete, including wildcards and tags taken from the ebook server protocol implementation. You should be able to click on a tag where they appear on the gui for a selected book to create a new search (which would include the selected book which is what makes it ok to replace the current search, not that I wouldn't say ok to a undo-redo mechanism).
4. where there is some sort of unobtrusive visual cue that books are in the same series\same author besides covers (so readers\users don't have to read the book title labels\extra tags to make sure), I suggest a line of color gradient (to be less dull than a single color but still distinct) each that doesn't repeat for non adjacent authors\series around a book border, probably based on hashing the author \ series names.
5. where you can select a book to get more information like detailed tags, detailed title and first paragraph text, etc probs with a floating label that overlaps other books and optionally moves the title text side to side in a single line if it doesn't fit (for phones). The title being single line in non selected mode is important for a predictable shelf gui, but the details could have another kind of visualization if hovering popup labels are not good for a phone gui.
6. A visual\textual mark of how much is the book read\completely read. Maybe one of how must time is estimated to the rest of the text to take to read (if you can I'm aware this is a black art involving user statistics, removing outliers and weird language dependent average speed of the platonic text as a start point).
7. A way to watch a dir\chose a dir as a 'library' to auto add\remove new books there and a extra gui to move the library (move the base dir, change the paths to change the old base path for the new).
8. Do not limit this dir to local directories \ allow SAF mounts (for instance RSAF version of webdav from the android standard file chooser and watch the remote dir - not sure this is actually possible mind you, but it would be neat not to require a local library folder.
9. Do not require a "Standard" file folder hierarchy when adding books manually, but still add them in the default ordering author-series inside author (these last 3 points wouldnt matter too much for e-readers that require a protocol like calibre and never walk the system but just mentioning it for completeness, file system walks are simple in most languages (now), custom sorting is simple, both at the same time is rare.

Of course, all this benefits from some 3rd party libraries that already solved these problems that the authors dont have time to do, for instance glazed lists and lucene (for java) allows the overlayed searches followed by a search pattern I described, I'm sure there are many others in other languages.

This is all complaining about client side gui, but I really do think that server side ebook servers can make this kind of advanced guis much easier to do and encourage to do if they have more streamlined protocols to get this information and not require ebook parsing to get it client side (for instance, the default ordering (chapter followed by author orderings) as base ordering from the server, cover thumbnails without parsing or the tag\series\time to read\remaining time to read info).

I'm not sure if OPDS is the right solution for this honestly since they needed to add a extension just to save page read count or covers, and insist in pagination without even a "how to" for clients to fake streaming pagination, much less custom/default ordering (ideally a user custom ordering built from others optionally so the client app or server admin could do their own default like 'series followed by author sorts' or 'publish dates followed by author sorts') without the client app just downloading the whole catalog, so I'm fairly sure that all the heavy lifting of a gui like this would be done client side.