Skip to content
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.

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

Suggestion for Enhancing Event Structure Standardization #891

Open
5 tasks done
jasgeo75 opened this issue Mar 9, 2024 · 1 comment
Open
5 tasks done

Suggestion for Enhancing Event Structure Standardization #891

jasgeo75 opened this issue Mar 9, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@jasgeo75
Copy link

jasgeo75 commented Mar 9, 2024

⚠️ Please check that this feature request hasn't been suggested before.

  • I searched previous Ideas in Discussions didn't find any similar feature requests.
  • I searched previous Issues didn't find any similar feature requests.

🔖 Feature description

I've noticed an opportunity to enhance the scalability and maintainability of server-client communication through the standardization of the event structure used in server-sent events. I believe this enhancement could make the system more robust and easier to work with, both for current and future contributors.

General Event Structure

Each event sent from the server follows this basic structure:

event: <event_type>
data: <json_formatted_data>

<event_type> is a string that specifies the type of the event (e.g., message, function_call, end-of-stream).
<json_formatted_data> is a JSON string that contains the event's data. The structure of this data varies depending on the event type.

Specific Event Formats

1. Message Event

Used for sending generic messages or data.

event: message
data: {
  "content": "<message_content>"
}
  • <message_content>: The actual content of the message. It can be any string, including structured data serialized as a string.

2. Function Call Event

Used for indicating a function call, including the function name and arguments.

event: function_call
data: {
  "function": "<function_name>",
  "args": {
    "<arg_name>": "<arg_value>",
    ...
  }
}
  • <function_name>: The name of the function being called.
  • <arg_name>: The name of an argument to the function.
  • <arg_value>: The value of the argument. There can be multiple arg_name: arg_value pairs depending on the function's signature.

3. End-of-Stream Event

Indicates that the stream of events has concluded.

event: end-of-stream
data: {
  "status": "completed"
}
  • "status": "completed": A fixed message indicating the stream has ended successfully.

Rationale

Implementing a uniform structure for server-sent events can simplify event handling logic on the client side, reducing development overhead and potential errors. It also lays a foundation for easier expansion and incorporation of new event types in the future, enhancing the project's adaptability and growth potential.

Acknowledgements

  • My issue title is concise and descriptive.
  • I have searched the existing issues to make sure this feature has not been requested yet.
  • I have provided enough information for the maintainers to understand and evaluate this request.
@jasgeo75 jasgeo75 added the enhancement New feature or request label Mar 9, 2024
@homanp
Copy link
Collaborator

homanp commented Mar 9, 2024

⚠️ Please check that this feature request hasn't been suggested before.

  • I searched previous Ideas in Discussions didn't find any similar feature requests.
  • I searched previous Issues didn't find any similar feature requests.

🔖 Feature description

I've noticed an opportunity to enhance the scalability and maintainability of server-client communication through the standardization of the event structure used in server-sent events. I believe this enhancement could make the system more robust and easier to work with, both for current and future contributors.

General Event Structure

Each event sent from the server follows this basic structure:


event: <event_type>

data: <json_formatted_data>

<event_type> is a string that specifies the type of the event (e.g., message, function_call, end-of-stream).

<json_formatted_data> is a JSON string that contains the event's data. The structure of this data varies depending on the event type.

Specific Event Formats

1. Message Event

Used for sending generic messages or data.


event: message

data: {

  "content": "<message_content>"

}

  • <message_content>: The actual content of the message. It can be any string, including structured data serialized as a string.

2. Function Call Event

Used for indicating a function call, including the function name and arguments.


event: function_call

data: {

  "function": "<function_name>",

  "args": {

    "<arg_name>": "<arg_value>",

    ...

  }

}

  • <function_name>: The name of the function being called.

  • <arg_name>: The name of an argument to the function.

  • <arg_value>: The value of the argument. There can be multiple arg_name: arg_value pairs depending on the function's signature.

3. End-of-Stream Event

Indicates that the stream of events has concluded.


event: end-of-stream

data: {

  "status": "completed"

}

  • "status": "completed": A fixed message indicating the stream has ended successfully.

Rationale

Implementing a uniform structure for server-sent events can simplify event handling logic on the client side, reducing development overhead and potential errors. It also lays a foundation for easier expansion and incorporation of new event types in the future, enhancing the project's adaptability and growth potential.

Acknowledgements

  • My issue title is concise and descriptive.
  • I have searched the existing issues to make sure this feature has not been requested yet.
  • I have provided enough information for the maintainers to understand and evaluate this request.

I agree with this 100%. Would you be up for contributing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants