Skip to content

Disambiguation between Integration and Publication #736

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Disambiguation between Integration and Publication #736

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -267,9 +267,13 @@ Writing to the log follows this flow:

Once an index has been returned, the new data is sequenced, but not necessarily integrated into the log.

As discussed above in [Integration](#integration), sequenced entries will be _asynchronously_ integrated into the log and be made available via the read API.
Some personalities may need to block until this has been performed, e.g. because they will provide the requester with an inclusion proof, which requires integration.
Such personalities are recommended to use [Synchronous Publication](#synchronous-publication) to perform this blocking.
As discussed above in [Integration](#integration) and [Publishing](#publishing),
sequenced entries will be first _asynchronously_ integrated into the log, and
then published on the read API by a second _asynchronous_ process. Some
personalities may need to block until this has been performed, e.g. because they
will provide the requester with an inclusion proof, which requires integration
and publication. Such personalities are recommended to use [Synchronous Publication](#synchronous-publication)
Comment on lines +270 to +275
Copy link
Collaborator

@AlCutter AlCutter Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
As discussed above in [Integration](#integration) and [Publishing](#publishing),
sequenced entries will be first _asynchronously_ integrated into the log, and
then published on the read API by a second _asynchronous_ process. Some
personalities may need to block until this has been performed, e.g. because they
will provide the requester with an inclusion proof, which requires integration
and publication. Such personalities are recommended to use [Synchronous Publication](#synchronous-publication)
As discussed above in [Integration](#integration) and [Publishing](#publishing),
sequenced entries will be _asynchronously_ integrated into the log, with a new `checkpoint` committing to these entries being published periodically by another asynchronous process.
Some personalities may need to block until this has been performed, e.g. because they will provide the requester with an inclusion proof, which requires both then integration of the entry and the publication of a new checkpoint to have completed. Such personalities are recommended to use [Synchronous Publication](#synchronous-publication)

Copy link
Contributor Author

@phbnf phbnf Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! More than stressing it out a second time, I think that the current phrasing is misleading: it suggests to wait for entries to be integrated and available, but that's not enough, one should really wait for a checkpoint to be published.

I like your wording better. I think that re-explaining the whole wheel every time is a bit cumbersome though. It makes sense here because we need to leave no room for confusion. I think that the concept of "publishing an entry" is relatively new, and I had not realized that it was already used in the Publishing section. If my understanding is correct, we use to refer to it as "integration", which included the "publication" part, but they have now been split in two.

Should we start using "entry publication" more broadly as part of the append lifecycle? Would there be a better word than "publishing" to avoid confusion with the fact that entries are already publicly available before being published? "entries commitment/entries are committed to"? I'm interested for the context of this PR, but also in general when speaking about log.

Suggested change
As discussed above in [Integration](#integration) and [Publishing](#publishing),
sequenced entries will be first _asynchronously_ integrated into the log, and
then published on the read API by a second _asynchronous_ process. Some
personalities may need to block until this has been performed, e.g. because they
will provide the requester with an inclusion proof, which requires integration
and publication. Such personalities are recommended to use [Synchronous Publication](#synchronous-publication)
As discussed above in [Integration](#integration) and [Publishing](#publishing),
sequenced entries will be {published/committed to} _asynchronously_: they will be integrated into the log, and a new `checkpoint` committing to these entries will be published on a clock by another asynchronous process.
Some personalities may need to block until this has been performed, e.g. because they will provide the requester with an inclusion proof, which requires both then integration of the entry and the publication of a new checkpoint to have completed. Such personalities are recommended to use [Synchronous Publication](#synchronous-publication)

to perform this blocking.

#### Reading from the Log

Expand Down
Loading