Closed sjehuda closed 3 weeks ago
id
is a misleading name for this value; contrary to the normal expectation, it's not stable at all and can be changed at any moment. It's meant for internal usage only, and is used primarily to micromanage the DB table. (It also determines printing order, and you'd expect it to also reflect the insertion order but the "DB compression" thing is implemented in a way that breaks said expectation completely.)
The bottom line is, the so-called id
is actually a transient value that defines current printing order of the record… and nothing else, pretty much. (In fact, I'd say that doing away with it altogether would be an improvement, compared to the current implementation.)
…Also, wouldn't summary
be more appropriate for the description? If I understand correctly, the content
element is meant to contain the entire document (or a link to it).
(Incidentally, both updated
and id
appear to be required elements in Atom, with the latter having to be permanent. Buku currently stores no dates at all, and none of the columns stored in DB are guaranteed to retain their value permanently :sweat_smile:)
…Also, wouldn't
summary
be more appropriate for the description? If I understand correctly, thecontent
is meant to contain the entire document (or a link to it).
You understand it correctly! It is me, who often treats "desc" as a text file, in which I have notes of multiple lines... And do not you worry about me, I also use my file ysstem to store textual data ';-D
(Incidentally, both updated and id appear to be required elements in Atom, with the latter having to be permanent. Buku currently stores no dates at all, and none of the columns stored in DB are guaranteed to retain their value permanently 😅)
Both can be utilized and then ignored by buku, unless we have custom fields of date, updated and xmpp_pubsub_node_id
Good day, gentlemen.
As you probably know, I have made BukuBot (see also #719) which is a chat bot which manages and handles bookmarks of multiple people simultaneously.
To actually integrate buku data into XMPP, we have resurted to XEP-0060: Publish-Subscribe which is an XMPP extension which allows to store data, and also turn any Jabber ID (XMPP account or service) into a publishing platform.
Libervia, Movim, and Rivista are publishing platforms that do not host any content on their own, and rather read Atompub/Atomsub PubSub nodes of XMPP accounts and services of XMPP server.
On the same premise, we have created Blasta, which makes use of PubSub as a platform to manage and synchronize bookmarks.
I have asked the team not to use the "rel" attribute of Atom Syndication Format, because buku does not support it yet (see #720), and I want that system to be compatible and coordinated with buku.
https://git.xmpp-it.net/sch/Blasta (not yet online)
I have created a proof of concept PubSub browser which has turned into a dynamix XHTML journal generator and which can give a good prespective of what Buku on XMPP would be.
https://git.xmpp-it.net/sch/Rivista
Rivista (journal in the Italian language) is able to read PubSub node items that are compliant with the Atom Syndication Format (RFC 4287);
It means, that namely XEP-0277 and XEP-0472 are supported, which further means that the uploaded data must be confined to the elements that RFC 4287 provides.
Of course, there is the "rel" attribute which allows own customizations, yet I focus on the commom elements.
buku provides
id
,url
,metadata
(i.e. title),tags
,desc
(i.e. description) andflags
.This is how I was thinking of populating Atom entries with buku data:
I am not sure yet how to handle the
id
, if needed.Please advise.