From 5521f3fd28c3117238d4998340d7ed02838e5309 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Wed, 22 Mar 2023 12:48:36 +0100 Subject: [PATCH] XEP-0060: Add data model informational text MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0060.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/xep-0060.xml b/xep-0060.xml index ef787a07..e35b5635 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -56,6 +56,7 @@ mw, pep
    +

  • Add data model informational text in Implementation Notes.

  • Fix spec approver

 @@ -5458,6 +5459,12 @@ And by opposing end them? + +

When implementing this protocol, it is often helpful to consider the data model behind it. Note that this section describes such a conceptual model for informational purposes only and does not define any requirements about how, where or in what format an implementation actually stores data.

+

A persistent pubsub node may be viewed as an ordered key-value store, where the ItemIDs are the keys, and the item payloads are the values.

+

The order of items is publication order, such that the most recently published is the “newest”. This holds true even if publishing with an ItemID that already exists on the node: the older item is dropped to preserve uniqueness of keys. This is sometimes referred to as “overwriting” in this document.

+

If published ItemIDs are always unique, a persistent node may also be viewed as a kind of “first in, first out” (FIFO) queue.

+

There are many possible triggers for sending an event notification to an entity for the currently published item or the last published item, as summarized below: