But this will never happen, since the primary goal of all the big players is to lock you into their infrastructure for profit, not make things better for you. Part of that protocol would be a user-definable storage/syncing location (Dropbox, personal server, etc.) that understands the protocol. More robust and feature-laden would be an agreement on a "current reading page" protocol between device and application developers. Just looking at one webpage in your browser probably uses more data than an entire eBook. But eBooks are very small (usually) in the grand scheme of things. The downside is that you are slinging around an entire books worth of data rather than just a few bytes to define the current page. Dropbox, email, a home FTP server - many ways.
Since the current reading location travels around with the book file, you can transfer that book file many different ways. That's why I like the idea of a meta-data field in the book. So when you want a solution that will work for eBooks "NOT from iBooks or Kindle", those developers are going to laugh in your face, since their entire goal is to tie you into their platform in the first place. And that middle-man server is designed to tie you into the applications infrastructure (with the primary goal being profit for the developer, not your convenience as a customer). Then, to make the book cross-device all you would need is a standard file syncing/sharing system, of which there are a bazillion out there.Ĭurrent solutions to this problem use something similar to a byte count I am sure, but they store that on a proprietary middle-man server that is application specific. Applications would need to read/write this meta-data field in real time. I would think a simple meta-data field in the EPUB/AZW file for the book could contain "current byte count" (where you are in the book). But the lack of widespread, workable solutions makes me think it must be. You wouldn't think this would be difficult to do.
0 kommentar(er)
