Replies: 11 comments 20 replies
-
I think such a spec should integrate with both OPDS 1.2 or 2.0 through a link, but I don't think that the "Synchronization Spec" would need both XML and JSON. In 2019, I would simply default to JSON or JSON-LD.
IMO that's all out of scope for such a document.
See https://drafts.opds.io/authentication-for-opds-1.0
I'm not sure what you're talking about with that one. If you mean a "well-known location", I don't think that's the way to go. The synchronization service should be discoverable using a link.
NYPL has developed something like that for SimplyE that integrates with OPDS, might be worth having @leonardr chiming in as well. |
Beta Was this translation helpful? Give feedback.
-
|
I'm using offline p2p synchronisation in my book reader. If you create compatible format json device to device synchronisation format I'm interested. Keep in mind synching across devices can create conflicts if book read by two devices and synchronisation software (create -conflict suffix files) and book reader (show conflict dialogs) should deal with it. I'm not interested in centralised only solution, not everyone want to setup a server. But I store a bit more information about books such as: {
"created": 1539355003077, // added to library
"last": 1553022686211, // last viewed
"title": "Fallout_ Equestria", // can be renamed by user
"position": [
95, // paragraph
0, // element
0 // char
],
"fontsize_6e01be161064d066": 45, // per device id font size, optimal to have per every device
"bookmarks": [
{
"last": 1553022479332, // last change time for syncronization
"name": "", // user name
"text": "A pony’s PipBuck generates an E.F.S. (Eyes-Forward Sparkle) that will indicate direction and help gauge whether the ponies or creatures around you are hostile.", // actual highlight text
"color": 0,
"start": [
97,
223,
0
],
"end": [
97,
269,
8
]
},
{
"last": 1553022485681,
"name": "",
"text": "And, perhaps most impressively, a PipBuck can magically aid you in a fight for brief periods of time through use of the S.A.T.S. (Stable-Tec Arcane Targeting Spell).",
"color": 0,
"start": [
97,
271,
0
],
"end": [
97,
323,
7
]
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
@axet If you have a moment, I have a couple of questions about your implementation:
Agreed, now that I've reviewed the 2.0 draft spec, JSON is definitely the way to go.
Agreed.
Makes sense to me.
I guess the foundation of the question is, should OPSS be a separate service with a separate discoverable URL, or integrated into OPDS in a standard location.
Would certainly love as much input from interested parties as possible. |
Beta Was this translation helpful? Give feedback.
-
|
It's also important to point out the work we're doing at Readium on locators, which could be the building block for such a service: https://readium.org/architecture/locators/ |
Beta Was this translation helpful? Give feedback.
-
|
We use the Web Annotation Protocol to sync bookmarks and last reading position across devices. At a glance it covers all the use cases here, and it's a well-defined protocol with multiple independent implementations. In particular, WAP defines a relation for discovery. Here's how we link to the annotation endpoint for a specific book in an OPDS 1.2 feed. Note the distinctive link relation and media type: Since annotation documents are JSON-LD, I believe you can store whatever extra information you want to keep, bibliographic or otherwise. The only extension we've had to make is a custom "motivation" (i.e. a reason why a person would create an annotation). We gave it the URI We don't promise to accept requests from any abitrary WAP client, but you can use WAP to extract all of your annotations from one of our servers. As Hadrien points out (and I think Fmstrat is also getting at), another crucial piece of the puzzle that's currently missing is a reliable way to identify a specific place in a book. We use EPUB's Content Fragment Identifier but they're not very reliable and we're hoping for something better to come out of Readium's "locators" project. |
Beta Was this translation helpful? Give feedback.
-
|
There is another spec that is used by software of reading software called OPDS-PS and has support in quite a few software that is similar to this. This allows for streaming pages one by one to the reader and thus allows for the server to keep track of progress. My app, Kavita, has implemented this. We also have support from Komga, Panels (client), Codex, and LANraragi https://github.com/anansi-project/opds-pse/blob/master/v1.2.md |
Beta Was this translation helpful? Give feedback.
-
|
Hello @majora2007, OPDS-PSE is an interesting mix of things:
It's balancing out all these features with a single templated URI and a few attributes thanks to smart decisions and the linear nature of comics/manga. There are restrictions and you could go beyond each of these features with various other standards out there, for instance:
It's a bit unfortunate that OPDS-PSE is based on OPDS 1.x since it could really benefit from the work done on OPDS 2.0 and RWPM:
|
Beta Was this translation helpful? Give feedback.
-
It would be good enough to test and validate that my opds 2 feed in divina profile is valid 😊 |
Beta Was this translation helpful? Give feedback.
-
|
We'll be able to tidy up the parsing if there are some issues. Don't hesitate to exchange with us (can be via thorium-support at edrlab.org) |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the the Divina spec, the e.g. off the top of my head: "links": [
{"rel": "self", "href": "http://example.org/manifest.json", "type": "application/divina+json"},
{"rel": "page",
"href": "http://example.org/{pageNum}/page.jpg",
"template": true,
"type": "image/jpeg",
"pageMin": 0,
"pageMax": 400 }
],Does not require 400 readingOrder elements and the method of display could be handled by the metadata and presentation schemas. |
Beta Was this translation helpful? Give feedback.
-
|
That would only work if all the pages have the same media type though, no? |
Beta Was this translation helpful? Give feedback.
-
|
@ajslater @majora2007 could you send me an email at [email protected]? It will be easier to set up a call than Github. |
Beta Was this translation helpful? Give feedback.
-
|
Yes. But I feel that is by far the most common situation.
…On Fri, Apr 21, 2023 at 9:29 PM Gauthier ***@***.***> wrote:
That would only work if all the pages have the same media type though, no?
—
Reply to this email directly, view it on GitHub
<#49 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACAKRV66PWB6JIRE6JVRVDXCNNAXANCNFSM6AAAAAAWKSUXP4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I've seen regularly, esp in Webtoons, where there are a mix of content types. Usually a gif and pngs, but sometimes jpgs written in for cover images. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps it would be nice to have the |
Beta Was this translation helpful? Give feedback.
-
|
Just to understand, this simplification is to reduce the complexity on server side? I don't know how the clients would feel about this, maybe having the full details make it easier and reduce work on the client. Idk. |
Beta Was this translation helpful? Give feedback.
-
|
There's a tiny one time penalty on the server side to do the page analysis
and then storage, but like, why do you want to send redundant information
over the wire every time you sever a publication? 25 to hundreds of json
fragments that all say "serve the next page exactly like the last one".
gzip or brotli isn't going to compress that.
…On Fri, Apr 21, 2023 at 10:44 PM Gauthier ***@***.***> wrote:
Just to understand, this simplification is to reduce the complexity on
server side? I don't know how the clients would feel about this, maybe
having the full details make it easier and reduce work on the client. Idk.
—
Reply to this email directly, view it on GitHub
<#49 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACAKRXY3TRWAN76Z3MAJETXCNV5BANCNFSM6AAAAAAWKSUXP4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Let's move this discussion to the Divina/RWPM repo instead since we're no longer discussing OPDS or synchronization. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone,
I'd like to make a proposal that may be of interest to you based on your backgrounds:
@janeczku - Author of Calibre-web
@HadrienGardeur - Maintainer of this repo and part of the OPDS community
@opds-community - The OPDS community
@geometer - Author or FBReader
Hopefully I've defined you all appropriately, but if not, my apologies. I'm sure there are others that make sense to pull into this conversion, and hopefully those already mentioned can reference them here.
While the OPDS spec is widely used (http://opds-spec.org/), one thing that has not yet been standardized in open readers is synchronization of read status, notes, bookmarks, and highlights. Many reader applications have this features (including FBReader), but while open, they are proprietary in-built systems.
My proposal is the creation of OPSS (Open Publication Synchronization Service) to accompany OPDS and hopefully be integrated into many of the solutions offering OPDS.
Initial considerations:
The following methods should be considered for implementation (naming is placeholder):
Anyone interested in pursuing this?
Add-ons
Adding the below to the chain because I believe they are likely candidates for initial implementations (along with calibre-web from a server side) of a cross-platform solution (common platforms, actively developed, and FOSS).
@axet - Author of Book Reader
@babluboy - Author of Bookwork
Previously discussed with interest from @geometer (Author of FBReader)
Perhaps MD5 the file for a unique id?
Count the words up the first word displayed on screen. That becomes the starting line for any reader, maybe? That also allows us to calculate percent read, and pages by defining average number of words per screen.
Beta Was this translation helpful? Give feedback.
All reactions