Logger Comment Formatting

[0x4007]

Change all logger comments to "new format" which looks more aesthetically pleasing.

Old Format

We should color code essentially the equivalent of HTTP 1xx 2xx 3xx 4xx 5xx class errors in these bot comments.

# 1xx Class (Informational Responses)

+ 2xx Class (Successful Responses)

@@ 3xx Class (Redirection Messages) @@

! 4xx Class (Client Error Responses)

- 5xx Class (Server Error Responses)

New Format

As it turns out, GitHub flavored markdown includes these handy color indicators. We can use the same color keys but instead of diff syntax, we use this syntax.

This should be applied across all kernel and plugin messages.

It might even be handy to rename the methods in our logger if its still attached to posting comments. The inspiration behind the rename is so that the class of message is no longer subjective.

logger.info();
logger.success();
logger.redirect();
logger.clientError();
logger.serverError();

Status Codes

Based on HTTP status codes, we should color code the responses. The only problem is that some of the headers can be misleading, but it does look a lot more aesthetically pleasing than the diffs. The left border in particular I think is a great minimal representation of the status.

Note

1xx

Tip

2xx

Important

3xx

Warning

4xx

Caution

5xx

Source Code

> [!NOTE]
> 1xx

> [!TIP]
> 2xx

> [!IMPORTANT]
> 3xx

> [!WARNING]
> 4xx

> [!CAUTION]
> 5xx

About HTTP Status Code Classes

HTTP status codes are standardized codes returned by web servers to indicate the result of a client's request. These codes are grouped into five classes, each signifying a different category of response:

---

1xx: Informational

Description: The 1xx class of status codes indicates that the server has received the request and is continuing the process. These are provisional responses, providing interim information while the server continues to process the request.

Common Status Codes:

• 100 Continue: Indicates that the initial part of the request has been received and the client should continue with the rest of the request.
• 101 Switching Protocols: Informs the client that the server is switching to a different protocol as requested.
• 102 Processing (WebDAV): Signals that the server has received and is processing the request, but no response is available yet.

---

2xx: Success

Description: The 2xx class signifies that the client's request was successfully received, understood, and accepted by the server.

Common Status Codes:

• 200 OK: The request has succeeded. The meaning varies depending on the HTTP method used.
• 201 Created: The request has been fulfilled, resulting in the creation of a new resource.
• 202 Accepted: The request has been accepted for processing, but the processing is not complete.
• 204 No Content: The server successfully processed the request and is not returning any content.
• 206 Partial Content: The server is delivering only part of the resource due to a range header sent by the client.

---

3xx: Redirection

Description: The 3xx class indicates that further action is needed to complete the request. This usually means a redirection to a different resource.

Common Status Codes:

• 301 Moved Permanently: The resource has been permanently moved to a new URL.
• 302 Found: The resource resides temporarily under a different URL.
• 303 See Other: The response can be found under a different URI and should be retrieved using a GET method.
• 304 Not Modified: Indicates that the resource has not been modified since the last request.
• 307 Temporary Redirect: The request should be repeated with another URI; however, future requests should still use the original URI.

---

4xx: Client Error

Description: The 4xx class signifies errors that appear to have been caused by the client. These codes indicate that the request contains bad syntax or cannot be fulfilled.

Common Status Codes:

• 400 Bad Request: The server cannot process the request due to a client error (e.g., malformed request syntax).
• 401 Unauthorized: Authentication is required and has failed or has not yet been provided.
• 403 Forbidden: The client does not have access rights to the content.
• 404 Not Found: The server cannot find the requested resource.
• 405 Method Not Allowed: The request method is known by the server but is not supported by the target resource.
• 408 Request Timeout: The server timed out waiting for the request.
• 409 Conflict: The request could not be completed due to a conflict with the current state of the resource.
• 410 Gone: The resource requested is no longer available and will not be available again.
• 429 Too Many Requests: The user has sent too many requests in a given amount of time ("rate limiting").

---

5xx: Server Error

Description: The 5xx class indicates that the server failed to fulfill a valid request. The server is aware that it has encountered an error or is otherwise incapable of performing the request.

Common Status Codes:

• 500 Internal Server Error: A generic error message when the server encounters an unexpected condition.
• 501 Not Implemented: The server either does not recognize the request method or lacks the ability to fulfill it.
• 502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server.
• 503 Service Unavailable: The server is not ready to handle the request, often due to maintenance or overload.
• 504 Gateway Timeout: The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
• 505 HTTP Version Not Supported: The server does not support the HTTP protocol version used in the request.

---

Understanding these status codes is essential for debugging web applications and ensuring efficient client-server communication. Each code provides specific information about what happened with a request, allowing developers to handle responses appropriately.

[whilefoo]

/start

[ubiquity-os-beta]

! This task does not reflect a business priority at the moment. You may start tasks with one of the following labels: Priority: 3 (High), Priority: 4 (Urgent), Priority: 5 (Emergency)

[whilefoo]

logger.info();
logger.success();
logger.redirect();
logger.clientError();
logger.serverError();

I think those don't make sense for a logger, redirect won't be used, clientError and serverError are better merged as error

Currently we have:

• logger.debug()
• logger.ok()
• logger.info()
• logger.error()
• logger.fatal()

I think these are fine, although ok() and info() are rarely used, we could rename ok() to success() because I think ok() is too neutral.

Note

logger.success() and logger.debug() but debug usually isn't posted

Tip

I think this one doesn't fit any of our methods

Important

Not sure about this one either

Warning

logger.error()

Caution

logger.fatal()

[gentlementlegen]

The functions basically match the console function names. Ok and info are used throughout most plug-ins, it's the green output and grey output respectively.

[whilefoo]

i feel like we should either make this note/tip/important/warning/caution as SDK functions separate from the logger or match them with logger methods, or both.

[0x4007]

I think those don't make sense for a logger, redirect won't be used,

Small details but I think the general spirit of this proposal still holds.

The idea is to guide the developer to think how http codes are standardized. It makes the log type less subjective to choose.

In practice we use "redirect" as developer verbose, purple, comments.

clientError and serverError are better merged as error

I disagree. Client error means the user messed up. Server error means that the code is messed up.

Examples:

• User invoked a command with an invalid parameter = client error
• user invoked a command correctly, but ens resolver broke = server error

recreating the visuals

I agree that the headers can be misleading. We can possibly recreate them without the headers by using images of the colored borders, but I'm not sure if we can float: left images in GitHub comments.

[whilefoo]

clientError and serverError are better merged as error

I disagree. Client error means the user messed up. Server error means that the code is messed up.

Examples:

• User invoked a command with an invalid parameter = client error
• user invoked a command correctly, but ens resolver broke = server error

If client error will appear as Warning and server error will appear as Caution, then the user won't differentiate between those two. Even if you add status codes only developers will understand that. It's the text that will the user that they used the command with invalid parameters. If we could modify the header that would make more sense

[0x4007]

The errors just need to be descriptive and it's fine.

[Sadaf-A]

/start

[ubiquity-os-beta]

! This task does not reflect a business priority at the moment. You may start tasks with one of the following labels: Priority: 3 (High), Priority: 4 (Urgent), Priority: 5 (Emergency)

[ubiquity-os-beta]

@whilefoo the deadline is at Wed, Dec 18, 2:01 AM UTC

[0x4007]

@whilefoo can you handle this

[ubiquity-os-beta]

Important

• Be sure to link a pull-request before the first reminder to avoid disqualification.
• Reminders will be sent every 3 days and 12 hours if there is no activity.
• Assignees will be disqualified after 7 days of inactivity.

[ubiquity-os-beta]

Passed the disqualification threshold and no activity is detected, removing assignees: @whilefoo.

[0x4007]

@whilefoo please handle this promptly