From 7c47c125197f47f1096c05d90494123d19fb1025 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Thu, 22 Feb 2018 08:30:44 -0800 Subject: [PATCH 01/13] Draft design goals for CloudEvents specification Signed-off-by: Sarah Allen --- about/design-goals.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 about/design-goals.md diff --git a/about/design-goals.md b/about/design-goals.md new file mode 100644 index 000000000..f98ebe207 --- /dev/null +++ b/about/design-goals.md @@ -0,0 +1,29 @@ +# CloudEvents Specification Design Goals + +CloudEvents are typically used in a distributed system to allow for services to be loosely coupled during development, then then configured with tight-coupling for specific applications. + +The goal of the CloudEvents specification is to allow for different cloud providers to create interoperable event systems, that allow for third-party tools and services to provide: +- new event sources +- new event consumers +- observability, such as monitoring, debugging and visualization, +- developer tools and libraries + +Key properties of the system: +- Source & action may be developed and deployed independently +- Trigger configuration allows for actions to be invoked based on a condition (e.g. for a specific event type generated by a source, optionally filtered by specific attribute values, such as a Function which is invoked when an image is uploaded to specific S3 or Google Cloud Storage “bucket” path +- Events are uniquely identified so that developers can write code that is idempotent +- Common meta-data attributes allow for observability via tools that are developed without knowledge of the specific implementation of an event system +- CloudEvents may be transported from source to action with different protocols. + +In order to achieve the above goals and desired system properties, the Serverless WG must agree on a common vocabulary with precise definitions describing the key elements of the system including: +- Source +- Action +- Trigger: the condition that causes an event to be transmitted from source to action +- Rule: the association of trigger + action + +In order to achieve the interoperability goals, the Serverless WG must describe: +- One or more common architectures that are in active use today or planned to be built by WG members +- How events are transported from source to action via at least one protocol +- Whether a shared trigger specification is needed, or if runtime interoperaability can be achieved independently, then shared configuration and/or API definition can be addressed as follow-on work +- Authorization model(s) + From 056257e1265bb312ee71ed36aec27cab36ea370b Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Sat, 24 Feb 2018 10:52:08 -0800 Subject: [PATCH 02/13] address feedback, wrap at 80 cols Signed-off-by: Sarah Allen --- about/design-goals.md | 49 +++++++++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 13 deletions(-) diff --git a/about/design-goals.md b/about/design-goals.md index f98ebe207..6393f11e6 100644 --- a/about/design-goals.md +++ b/about/design-goals.md @@ -1,29 +1,52 @@ # CloudEvents Specification Design Goals -CloudEvents are typically used in a distributed system to allow for services to be loosely coupled during development, then then configured with tight-coupling for specific applications. +CloudEvents are typically used in a distributed system to allow for services to +be loosely coupled during development, then configured with tight-coupling for +specific applications. -The goal of the CloudEvents specification is to allow for different cloud providers to create interoperable event systems, that allow for third-party tools and services to provide: +The goal of the CloudEvents specification is to define interoperability of event +systems that allow cloud providers, third-party tools and services to provide: - new event sources - new event consumers - observability, such as monitoring, debugging and visualization, - developer tools and libraries -Key properties of the system: +## Key properties of the system: - Source & action may be developed and deployed independently -- Trigger configuration allows for actions to be invoked based on a condition (e.g. for a specific event type generated by a source, optionally filtered by specific attribute values, such as a Function which is invoked when an image is uploaded to specific S3 or Google Cloud Storage “bucket” path -- Events are uniquely identified so that developers can write code that is idempotent -- Common meta-data attributes allow for observability via tools that are developed without knowledge of the specific implementation of an event system +- Trigger configuration allows for actions to be invoked based on a condition +(e.g. for a specific event type generated by a source, optionally filtered by +specific attribute values, such as a Function which is invoked when an image is +uploaded to specific S3 or Google Cloud Storage “bucket” path) +- Events are uniquely identified to facilitate developer velocity and tooling: + - a unique idenfier allows for idempotency for reliable implementation + - structured event definitions allow the consumer to rely on a specific format +- Common metadata attributes allow for observability via tools whithout +knowledge of the specific implementation of an event system and also can provide +value without detailed handling of the specifics of the unique event data - CloudEvents may be transported from source to action with different protocols. -In order to achieve the above goals and desired system properties, the Serverless WG must agree on a common vocabulary with precise definitions describing the key elements of the system including: -- Source -- Action -- Trigger: the condition that causes an event to be transmitted from source to action +In order to achieve the above goals and desired system properties, the +Serverless WG must agree on a common vocabulary with precise definitions +describing the key elements of the system including: +- [Source](../spec.md#source) +- Action +- Trigger: the condition that causes an event to be transmitted from source to +action - Rule: the association of trigger + action In order to achieve the interoperability goals, the Serverless WG must describe: -- One or more common architectures that are in active use today or planned to be built by WG members +- One or more common architectures that are in active use today or planned to be +built by WG members - How events are transported from source to action via at least one protocol -- Whether a shared trigger specification is needed, or if runtime interoperaability can be achieved independently, then shared configuration and/or API definition can be addressed as follow-on work -- Authorization model(s) +- Whether a shared trigger specification is needed, or if runtime +interoperability can be achieved independently, then shared configuration and/or +API definition can be addressed as follow-on work +- Authorization model(s) that control access and execution permissions + + +## Non-Goals of this spec +The following non-goals may be follow-on work, yet would not be included in the +1.0 specification. +- Function build and invocation process +- Language-specific runtime APIs From 9b91e3401b243f92c29b619f6a50719a199988ea Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Tue, 27 Feb 2018 22:12:25 -0800 Subject: [PATCH 03/13] address feedback - move WG process into readme, with link to spec & goals - clarify that triggers can be custom to the system using CloudEvents - allow for run-time configuration Signed-off-by: Sarah Allen --- README.md | 19 +++++++++++++++++++ about/design-goals.md | 41 +++++++++++++++++++++++------------------ 2 files changed, 42 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index dc820cc7d..850c2a558 100644 --- a/README.md +++ b/README.md @@ -21,6 +21,25 @@ ranging from major cloud providers to popular SaaS companies. Our end goal is to offer this specification to the [Cloud Native Computing Foundation](https://www.cncf.io/). +## Working Group process + +The CNCF Serverless WG is working to formalize the [specification](spec.md) +based on [design goals](about/design-goals.md) which focus on interoperability +between systems which generate and respond to events. + +In order to achieve these goals, the Serverless WG must describe: +- Common attributes of an *event* that facilitate interoperability +- One or more common architectures that are in active use today or planned to be +built by WG members +- How events are transported from source to action via at least one protocol +- Authorization model(s) that control access and execution permissions + +### Non-Goals of this specification +The following non-goals will not be part of the specification. +- Function build and invocation process +- Language-specific runtime APIs +- Selecting a single identity/access control system + ## Communications We have google group for e-mail communications: diff --git a/about/design-goals.md b/about/design-goals.md index 6393f11e6..41e3d5360 100644 --- a/about/design-goals.md +++ b/about/design-goals.md @@ -1,8 +1,8 @@ # CloudEvents Specification Design Goals CloudEvents are typically used in a distributed system to allow for services to -be loosely coupled during development, then configured with tight-coupling for -specific applications. +be loosely coupled during development, then may be configured with +tight-coupling for specific applications or dynamically configured at runtime. The goal of the CloudEvents specification is to define interoperability of event systems that allow cloud providers, third-party tools and services to provide: @@ -29,24 +29,29 @@ In order to achieve the above goals and desired system properties, the Serverless WG must agree on a common vocabulary with precise definitions describing the key elements of the system including: - [Source](../spec.md#source) -- Action +- Action: An action consumes an event, producing a behavior or effect which was +triggered by a specific *occurrence* from a specific *source*. While the +details of how events are delivered to an action is outside of the scope of the +specification, the purpose of generating an *event* is typcially to allow other +systems to easily react to changes in a source that they do not control. The +*source* and action are often built by different developers. + +Examples: +- the *source* is a managed service and the *action* is custom +code in a serverless Function (such as AWS Lambda or Google Cloud Functions). +- the *source* is an IoT device and the *event* is transmitted through an API +Gateway to the *action*, a service provided by a different developer. + +The events system provides a way for the developer to specify which *event* +should be delivered to which *action*. The specific mechanism is outside the +scope of the specification, yet the following definitions faciltate an +understanding of how CloudEvent are typically used in context: - Trigger: the condition that causes an event to be transmitted from source to action - Rule: the association of trigger + action -In order to achieve the interoperability goals, the Serverless WG must describe: -- One or more common architectures that are in active use today or planned to be -built by WG members -- How events are transported from source to action via at least one protocol -- Whether a shared trigger specification is needed, or if runtime -interoperability can be achieved independently, then shared configuration and/or -API definition can be addressed as follow-on work -- Authorization model(s) that control access and execution permissions - - -## Non-Goals of this spec -The following non-goals may be follow-on work, yet would not be included in the -1.0 specification. -- Function build and invocation process -- Language-specific runtime APIs +Systems which generate events can have independent mechanisms for how triggers +are specified and how rules are stored and evaluated. + + From 6269ffdc77ad7561a194ce8a34f38b5091f6f8b4 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Thu, 1 Mar 2018 08:47:48 -0800 Subject: [PATCH 04/13] move design goals into spec Signed-off-by: Sarah Allen --- README.md | 2 +- about/design-goals.md | 57 ------------------------------------- spec.md | 66 +++++++++++++++++++++++++++++++++++++++---- 3 files changed, 62 insertions(+), 63 deletions(-) delete mode 100644 about/design-goals.md diff --git a/README.md b/README.md index 850c2a558..f2e3f6cbd 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ to offer this specification to the ## Working Group process The CNCF Serverless WG is working to formalize the [specification](spec.md) -based on [design goals](about/design-goals.md) which focus on interoperability +based on [design goals](spec#design-goals) which focus on interoperability between systems which generate and respond to events. In order to achieve these goals, the Serverless WG must describe: diff --git a/about/design-goals.md b/about/design-goals.md deleted file mode 100644 index 41e3d5360..000000000 --- a/about/design-goals.md +++ /dev/null @@ -1,57 +0,0 @@ -# CloudEvents Specification Design Goals - -CloudEvents are typically used in a distributed system to allow for services to -be loosely coupled during development, then may be configured with -tight-coupling for specific applications or dynamically configured at runtime. - -The goal of the CloudEvents specification is to define interoperability of event -systems that allow cloud providers, third-party tools and services to provide: -- new event sources -- new event consumers -- observability, such as monitoring, debugging and visualization, -- developer tools and libraries - -## Key properties of the system: -- Source & action may be developed and deployed independently -- Trigger configuration allows for actions to be invoked based on a condition -(e.g. for a specific event type generated by a source, optionally filtered by -specific attribute values, such as a Function which is invoked when an image is -uploaded to specific S3 or Google Cloud Storage “bucket” path) -- Events are uniquely identified to facilitate developer velocity and tooling: - - a unique idenfier allows for idempotency for reliable implementation - - structured event definitions allow the consumer to rely on a specific format -- Common metadata attributes allow for observability via tools whithout -knowledge of the specific implementation of an event system and also can provide -value without detailed handling of the specifics of the unique event data -- CloudEvents may be transported from source to action with different protocols. - -In order to achieve the above goals and desired system properties, the -Serverless WG must agree on a common vocabulary with precise definitions -describing the key elements of the system including: -- [Source](../spec.md#source) -- Action: An action consumes an event, producing a behavior or effect which was -triggered by a specific *occurrence* from a specific *source*. While the -details of how events are delivered to an action is outside of the scope of the -specification, the purpose of generating an *event* is typcially to allow other -systems to easily react to changes in a source that they do not control. The -*source* and action are often built by different developers. - -Examples: -- the *source* is a managed service and the *action* is custom -code in a serverless Function (such as AWS Lambda or Google Cloud Functions). -- the *source* is an IoT device and the *event* is transmitted through an API -Gateway to the *action*, a service provided by a different developer. - -The events system provides a way for the developer to specify which *event* -should be delivered to which *action*. The specific mechanism is outside the -scope of the specification, yet the following definitions faciltate an -understanding of how CloudEvent are typically used in context: -- Trigger: the condition that causes an event to be transmitted from source to -action -- Rule: the association of trigger + action - -Systems which generate events can have independent mechanisms for how triggers -are specified and how rules are stored and evaluated. - - - diff --git a/spec.md b/spec.md index f37e03aed..75c72ff84 100644 --- a/spec.md +++ b/spec.md @@ -5,6 +5,7 @@ of event data. ## Table of Contents - [Overview](#overview) +- [Deisgn Goals](#design-goals) - [Status](#status) - [Notations and Terminology](#notations-and-terminology) - [Context Attributes](#context-attributes) @@ -26,6 +27,61 @@ Enter CloudEvents, a specification for describing event data in a common way. CloudEvents seeks to ease event declaration and delivery across services, platforms and beyond. +# Design Goals + +CloudEvents are typically used in a distributed system to allow for services to +be loosely coupled during development, then may be configured with +tight-coupling for specific applications or dynamically configured at runtime. + +The goal of the CloudEvents specification is to define interoperability of event +systems that allow cloud providers, third-party tools and services to provide: +- new event sources +- new event consumers +- observability, such as monitoring, debugging and visualization, +- developer tools and libraries + +## Key properties of the system: +- Source & action may be developed and deployed independently +- Trigger configuration allows for actions to be invoked based on a condition +(e.g. for a specific event type generated by a source, optionally filtered by +specific attribute values, such as a Function which is invoked when an image is +uploaded to specific S3 or Google Cloud Storage “bucket” path) +- Events are uniquely identified to facilitate developer velocity and tooling: + - a unique idenfier allows for idempotency for reliable implementation + - structured event definitions allow the consumer to rely on a specific format +- Common metadata attributes allow for observability via tools whithout +knowledge of the specific implementation of an event system and also can provide +value without detailed handling of the specifics of the unique event data +- CloudEvents may be transported from source to action with different protocols. + +In order to achieve the above goals and desired system properties, the +Serverless WG must agree on a common vocabulary with precise definitions +describing the key elements of the system including: +- [Source](../spec.md#source) +- Action: An action consumes an event, producing a behavior or effect which was +triggered by a specific *occurrence* from a specific *source*. While the +details of how events are delivered to an action is outside of the scope of the +specification, the purpose of generating an *event* is typcially to allow other +systems to easily react to changes in a source that they do not control. The +*source* and action are often built by different developers. + +Examples: +- the *source* is a managed service and the *action* is custom +code in a serverless Function (such as AWS Lambda or Google Cloud Functions). +- the *source* is an IoT device and the *event* is transmitted through an API +Gateway to the *action*, a service provided by a different developer. + +The events system provides a way for the developer to specify which *event* +should be delivered to which *action*. The specific mechanism is outside the +scope of the specification, yet the following definitions faciltate an +understanding of how CloudEvent are typically used in context: +- Trigger: the condition that causes an event to be transmitted from source to +action +- Rule: the association of trigger + action + +Systems which generate events can have independent mechanisms for how triggers +are specified and how rules are stored and evaluated. + ## Status At this time the specification is focused on the following scope: @@ -64,9 +120,9 @@ be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). This specification defines the following terms: #### Occurrence -An "occurrence" is the capture of a statement of fact during the operation of -a software system. This might occur because of a signal raised by the system or -a signal being observed by the system, because of a state change, because of +An "occurrence" is the capture of a statement of fact during the operation of +a software system. This might occur because of a signal raised by the system or +a signal being observed by the system, because of a state change, because of a timer elapsing, or any other noteworthy activity. For example, a device might go into an alert state because the battery is low, or a virtual machine is about to perform a scheduled reboot. @@ -205,7 +261,7 @@ that contains both context and data). ### content-type * Type: String per [RFC 2046](https://tools.ietf.org/html/rfc2046) -* Description: Describe the data encoding format +* Description: Describe the data encoding format * Constraints: * OPTIONAL * If present, MUST adhere to the format specified in @@ -228,7 +284,7 @@ that contains both context and data). ### data * Type: Arbitrary payload * Description: The event payload. The payload depends on the event-type, - schema-url and event-type-version, the payload is encoded into a media format + schema-url and event-type-version, the payload is encoded into a media format which is specified by the content-type attribute (e.g. application/json). * Constraints: * OPTIONAL From 89cd4df9d1e23349037efa074bc19771d447ef1f Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Thu, 1 Mar 2018 08:50:28 -0800 Subject: [PATCH 05/13] typo s/./:/ Signed-off-by: Sarah Allen --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f2e3f6cbd..fef0bd48e 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ built by WG members - Authorization model(s) that control access and execution permissions ### Non-Goals of this specification -The following non-goals will not be part of the specification. +The following non-goals will not be part of the specification: - Function build and invocation process - Language-specific runtime APIs - Selecting a single identity/access control system From 94519beb6c095b2a1f1086ac2c1628a20d042931 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Thu, 1 Mar 2018 08:52:42 -0800 Subject: [PATCH 06/13] fix link Signed-off-by: Sarah Allen --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fef0bd48e..e51fb6cfb 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ to offer this specification to the ## Working Group process The CNCF Serverless WG is working to formalize the [specification](spec.md) -based on [design goals](spec#design-goals) which focus on interoperability +based on [design goals](spec.md#design-goals) which focus on interoperability between systems which generate and respond to events. In order to achieve these goals, the Serverless WG must describe: From d06f0a79f56af577ca31d1a478722eee7a22e3dc Mon Sep 17 00:00:00 2001 From: Rachel Myers Date: Wed, 7 Mar 2018 15:21:53 -0800 Subject: [PATCH 07/13] Remove product references; typos Signed-off-by: Rachel Myers --- spec.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/spec.md b/spec.md index 75c72ff84..7b904957d 100644 --- a/spec.md +++ b/spec.md @@ -45,11 +45,11 @@ systems that allow cloud providers, third-party tools and services to provide: - Trigger configuration allows for actions to be invoked based on a condition (e.g. for a specific event type generated by a source, optionally filtered by specific attribute values, such as a Function which is invoked when an image is -uploaded to specific S3 or Google Cloud Storage “bucket” path) +uploaded to a specific bucket in an object store). - Events are uniquely identified to facilitate developer velocity and tooling: - - a unique idenfier allows for idempotency for reliable implementation + - a unique identifier allows for idempotency for reliable implementation - structured event definitions allow the consumer to rely on a specific format -- Common metadata attributes allow for observability via tools whithout +- Common metadata attributes allow for observability via tools without knowledge of the specific implementation of an event system and also can provide value without detailed handling of the specifics of the unique event data - CloudEvents may be transported from source to action with different protocols. @@ -66,8 +66,8 @@ systems to easily react to changes in a source that they do not control. The *source* and action are often built by different developers. Examples: -- the *source* is a managed service and the *action* is custom -code in a serverless Function (such as AWS Lambda or Google Cloud Functions). +- the *source* is a managed service and the *action* is custom code in a +serverless Function. - the *source* is an IoT device and the *event* is transmitted through an API Gateway to the *action*, a service provided by a different developer. From 751a01a1f1dcd594671ea2f988fe001f7dc1d80d Mon Sep 17 00:00:00 2001 From: Rachel Myers Date: Wed, 7 Mar 2018 15:34:17 -0800 Subject: [PATCH 08/13] Typo fixes :art: Signed-off-by: Rachel Myers --- spec.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/spec.md b/spec.md index 7b904957d..6a355e837 100644 --- a/spec.md +++ b/spec.md @@ -5,7 +5,7 @@ of event data. ## Table of Contents - [Overview](#overview) -- [Deisgn Goals](#design-goals) +- [Design Goals](#design-goals) - [Status](#status) - [Notations and Terminology](#notations-and-terminology) - [Context Attributes](#context-attributes) @@ -61,7 +61,7 @@ describing the key elements of the system including: - Action: An action consumes an event, producing a behavior or effect which was triggered by a specific *occurrence* from a specific *source*. While the details of how events are delivered to an action is outside of the scope of the -specification, the purpose of generating an *event* is typcially to allow other +specification, the purpose of generating an *event* is typically to allow other systems to easily react to changes in a source that they do not control. The *source* and action are often built by different developers. @@ -73,8 +73,8 @@ Gateway to the *action*, a service provided by a different developer. The events system provides a way for the developer to specify which *event* should be delivered to which *action*. The specific mechanism is outside the -scope of the specification, yet the following definitions faciltate an -understanding of how CloudEvent are typically used in context: +scope of the specification, yet the following definitions facilitate an +understanding of how CloudEvents are typically used in context: - Trigger: the condition that causes an event to be transmitted from source to action - Rule: the association of trigger + action From 1bb87006dd791b98ef1e2a3939e3b5f81c175cd1 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Tue, 13 Mar 2018 07:24:36 -0700 Subject: [PATCH 09/13] simplified design goals based on community discussions Signed-off-by: Sarah Allen --- README.md | 2 +- spec.md | 66 ++++++++++++++----------------------------------------- 2 files changed, 18 insertions(+), 50 deletions(-) diff --git a/README.md b/README.md index e51fb6cfb..68adf9710 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,7 @@ In order to achieve these goals, the Serverless WG must describe: - One or more common architectures that are in active use today or planned to be built by WG members - How events are transported from source to action via at least one protocol -- Authorization model(s) that control access and execution permissions +- Identify and resolve whatever else is needed for interoperability ### Non-Goals of this specification The following non-goals will not be part of the specification: diff --git a/spec.md b/spec.md index 6a355e837..be3625e4d 100644 --- a/spec.md +++ b/spec.md @@ -30,57 +30,25 @@ platforms and beyond. # Design Goals CloudEvents are typically used in a distributed system to allow for services to -be loosely coupled during development, then may be configured with -tight-coupling for specific applications or dynamically configured at runtime. +be loosely coupled during development, deployed independently, and later +can be connected to create new applications. The goal of the CloudEvents specification is to define interoperability of event -systems that allow cloud providers, third-party tools and services to provide: -- new event sources -- new event consumers -- observability, such as monitoring, debugging and visualization, -- developer tools and libraries - -## Key properties of the system: -- Source & action may be developed and deployed independently -- Trigger configuration allows for actions to be invoked based on a condition -(e.g. for a specific event type generated by a source, optionally filtered by -specific attribute values, such as a Function which is invoked when an image is -uploaded to a specific bucket in an object store). -- Events are uniquely identified to facilitate developer velocity and tooling: - - a unique identifier allows for idempotency for reliable implementation - - structured event definitions allow the consumer to rely on a specific format -- Common metadata attributes allow for observability via tools without -knowledge of the specific implementation of an event system and also can provide -value without detailed handling of the specifics of the unique event data -- CloudEvents may be transported from source to action with different protocols. - -In order to achieve the above goals and desired system properties, the -Serverless WG must agree on a common vocabulary with precise definitions -describing the key elements of the system including: -- [Source](../spec.md#source) -- Action: An action consumes an event, producing a behavior or effect which was -triggered by a specific *occurrence* from a specific *source*. While the -details of how events are delivered to an action is outside of the scope of the -specification, the purpose of generating an *event* is typically to allow other -systems to easily react to changes in a source that they do not control. The -*source* and action are often built by different developers. - -Examples: -- the *source* is a managed service and the *action* is custom code in a -serverless Function. -- the *source* is an IoT device and the *event* is transmitted through an API -Gateway to the *action*, a service provided by a different developer. - -The events system provides a way for the developer to specify which *event* -should be delivered to which *action*. The specific mechanism is outside the -scope of the specification, yet the following definitions facilitate an -understanding of how CloudEvents are typically used in context: -- Trigger: the condition that causes an event to be transmitted from source to -action -- Rule: the association of trigger + action - -Systems which generate events can have independent mechanisms for how triggers -are specified and how rules are stored and evaluated. +systems that allow services to produce or consume events, where the producer and +consumer can be developed and deployed independently. A producer must be able +to generate events before a consumer is listening, and a consumer must be able +to express an interest in an event or class of events that is not yet being +produced. + +To this end, the specification will include common metadata attributes of an +event that facilitate interoperability, where the event does not contain any +details about the consumer or transport that might be use to send the event. + +## Non-Goals +The following will not be part of the specification: +Function build and invocation process +Language-specific runtime APIs +Selecting a single identity/access control system ## Status At this time the specification is focused on the following scope: From 70528c80006abfdb8757439bd3c930e68d9f11c9 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Wed, 14 Mar 2018 06:44:42 -0700 Subject: [PATCH 10/13] remove non-goals from README (since it is now in the spec) also fixed formatting of non-goals section of spec Signed-off-by: Sarah Allen --- README.md | 6 ------ spec.md | 6 +++--- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 68adf9710..d67c7996e 100644 --- a/README.md +++ b/README.md @@ -34,12 +34,6 @@ built by WG members - How events are transported from source to action via at least one protocol - Identify and resolve whatever else is needed for interoperability -### Non-Goals of this specification -The following non-goals will not be part of the specification: -- Function build and invocation process -- Language-specific runtime APIs -- Selecting a single identity/access control system - ## Communications We have google group for e-mail communications: diff --git a/spec.md b/spec.md index be3625e4d..01e51c7c2 100644 --- a/spec.md +++ b/spec.md @@ -46,9 +46,9 @@ details about the consumer or transport that might be use to send the event. ## Non-Goals The following will not be part of the specification: -Function build and invocation process -Language-specific runtime APIs -Selecting a single identity/access control system +* Function build and invocation process +* Language-specific runtime APIs +* Selecting a single identity/access control system ## Status At this time the specification is focused on the following scope: From 14f56718d448c849326a982f476e75540c834b27 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Wed, 14 Mar 2018 06:58:12 -0700 Subject: [PATCH 11/13] must => MUST Signed-off-by: Sarah Allen --- spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec.md b/spec.md index 01e51c7c2..23800174e 100644 --- a/spec.md +++ b/spec.md @@ -35,8 +35,8 @@ can be connected to create new applications. The goal of the CloudEvents specification is to define interoperability of event systems that allow services to produce or consume events, where the producer and -consumer can be developed and deployed independently. A producer must be able -to generate events before a consumer is listening, and a consumer must be able +consumer can be developed and deployed independently. A producer MUST be able +to generate events before a consumer is listening, and a consumer MUST be able to express an interest in an event or class of events that is not yet being produced. From 9d5c84506db92a848b9af3c11ab2cb900fb4f640 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Wed, 14 Mar 2018 07:12:05 -0700 Subject: [PATCH 12/13] process language more generic to be consistent with design goals We decided to avoid terms that are in the spec in the overview and goals, at least until we align on definitions, then we can revise later if that seems helpful. This edit fixes process section of README to be consistent with that philosophy. Signed-off-by: Sarah Allen --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index d67c7996e..28e4827c7 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ In order to achieve these goals, the Serverless WG must describe: - Common attributes of an *event* that facilitate interoperability - One or more common architectures that are in active use today or planned to be built by WG members -- How events are transported from source to action via at least one protocol +- How events are transported from producer to consumer via at least one protocol - Identify and resolve whatever else is needed for interoperability ## Communications From 84a821f43c779c1694aa03d713aa8c4cda762e37 Mon Sep 17 00:00:00 2001 From: Sarah Allen Date: Wed, 14 Mar 2018 07:29:18 -0700 Subject: [PATCH 13/13] shift back to using general term (must => can) Signed-off-by: Sarah Allen --- spec.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/spec.md b/spec.md index 23800174e..db183bea5 100644 --- a/spec.md +++ b/spec.md @@ -35,10 +35,9 @@ can be connected to create new applications. The goal of the CloudEvents specification is to define interoperability of event systems that allow services to produce or consume events, where the producer and -consumer can be developed and deployed independently. A producer MUST be able -to generate events before a consumer is listening, and a consumer MUST be able -to express an interest in an event or class of events that is not yet being -produced. +consumer can be developed and deployed independently. A producer can generate +events before a consumer is listening, and a consumer can express an interest in +an event or class of events that is not yet being produced. To this end, the specification will include common metadata attributes of an event that facilitate interoperability, where the event does not contain any