duglin

Message Definition Matching

One popular use of a Message Registry is to be a catalog of Message definitions that are used to validate incoming messages. In these scenarios, the receiver of a message might need to "match" it to the corresponding Message definition that the message is meant to adhere to. This specification does not mandate how this "matching" is done. For example, matching headers or schema of the incoming message to the Message definitions in the Registry is one option.

In a Registry with many Message definitions, and each one of those having

duglin

Release creation process (e.g. create v1.0.3)

• edit all files to reference v1.0.3
• create a new v1.0.3 tag

If we ever needed to update v1.0.3 w/o picking up newer changes on main:

• create a v-1.0.3 branch (pick a better name) from v1.0.3 tag
• merge PR in that branch
• delete v1.0.3 tag
• create a new v1.0.3 tag pointing to the HEAD of v-1.0.3 branch

duglin

dirs/d1/files/f1 exists

PUT /dirs/d2/files/f2
   { xbase: /dirs/d1/files/f1/versions/v1 }
   creates a v1 pointing to d1/f1

POST /dirs/d2/files/f2  (creating a new version)
  {}
  creates a v2 w/o a pointer

duglin

asdasd

asdasd

<hello> id qwe

asdasd

duglin

{
  "specversion": "0.5",
  "id": "Endpoints",
  "name": "Endpoints Registry",
  "epoch": 1,
  "self": "http://ubuntu:8080/reg-Endpoints/",
  "description": "An impl of the endpoints spec",
  "documentation": "https://github.com/duglin/xreg-github",
  "createdat": "2024-05-08T19:19:27.851502385Z",
  "modifiedat": "2024-05-08T19:19:27.860021511Z",

duglin

Current version of the spec defines epoch as:

---

Epoch: Description: The Discovery Endpoint's epoch value for this Service Entry. This specification does not mandate any particular semantic meaning to the value used. For example, implementations are free to use a value that represents a timestamp or could choose to simply use a monotonically increasing number. The only requirement is that the value MUST always increase each time the Service Entry is updated. This allows for a quick integer comparision to determine which version of this Service Entry is the latest - meaning, the one with the larger integer value.

---

duglin

Discovery and Subscroption Primer - WIP

Abstract

This non-normative document provides an overview of the Discovery and Subscription API specifications. It is meant to complement those specifications to provide additional background and insight into the history and design decisions made during their development. This allows the specification itself to focus on the normative technical details.

duglin

interface CloudEvent {
  ...
  String getSubject();
	ZonedDateTime getTime();
  Map<String, Object> getExtensions();
  Object getExtension(key);
  T/Object get(key);                     // used for spec attrs and extensions
}

interface CloudEventBuilder {

duglin

CNCF Serverless SIG Charter

Introduction

This is the charter referred to in “CNCF SIGs” by the CNCF TOC, and consistent with the proposed SIG definition.

Borrowing from the [Serverless

duglin

1. line 1
2. line 2 1.1. line 2.1 1.1. line 2.2

test link