add websockets

[t-rog]

Co-Authored-By: SwitchUpCB 81384235+switchupcb@users.noreply.github.com

[switchupcb]

Event Handling

Event Handling will use two functions in order to avoid type asserting.

Function One

The first function will be a generic function to handle all events. Upon receiving events, this function will be called with a goroutine to prevent it's code from blocking the main thread.

The steps are as follows:

1. A JSON FILE is received and passed to onEvent(bot *Client, data []byte) where data represents the JSON file.
2. The op is checked using a generic/custom/gjson marshal.
3. A global map is checked for the op. The purpose of this map is to provide event handlers for events that must be handled (and usually in the same way). For example, heartbeat events which require continuous pinging to discord, or resume events.
4. A custom map is checked for the op. The purpose of this map is to provide events handlers for events that are handled by the bot. For example, events that are defined by the user using function two.

Map may be replaced by an alternate data structure or switch.

Function Two

Function two represents the disgo UI for event handling. This can be defined in a similar manner to the Send() function such as event.Add(bot, func() { ... } to add an event handler to the bot, or similar to the current method in the proof of concept README.

// Define an event handler.
handler := disgo.EventHandler{
    Event: disgo.EventInteractionCreate,
    Call: func (i disgo.ResourceInteraction) {
        log.Printf("main called by %s", i.User.Username)
    },
}

// Add the event handler to the bot.
bot.Add(handler)

Regardless of the choice, we must allow the user to determine the event they are using before runtime, such that we can also add it to the bot at compile time in the correct list of handlers.

Function Three

The "third function" represents the goroutines that run the event handler functions from the onEvent thread.

[switchupcb]

Event names were added using the following code:

import re

# format formats the given string from CapitalWord to CAPITAL_WORD.
def formatString(s):
    words = re.findall('[A-Z][^A-Z]*', s)
    formatted = ''
    for word in words:
        formatted += word.upper() + "_"
    
    return formatted[:len(formatted) - 1]

# flag is appended to the start of the line.
flag = "FlagGatewayEventName"

# create the new file.
newfile = ""
lines = file.split("\n")
for line in lines:
    newfile += flag + line + " = " + '"' + formatString(line) + '"' + "\n"

print(newfile)

[switchupcb]

This outline works in essentially the same way as above, however we can NOT use the opcode itself to determine the event.

Instead, onEvent is used to determine the Opcode, and if Op == 0, then we can use t (EventName) with the handle function to handle the actual event. This entails adding generated code which — for each event — unmarshals d into the respective object, and then runs the bot's handler functions on a goroutine.

The original idea to use a map was thwarted because a map[string]func(interface{}) is not usable (since a func(interface{}) is NOT equivalent to a func(*<Event>)). In contrast, a func(<whatever>) is equivalent to a interface{}, but this warrants unnecessary complexity and type assertions at some point. We can avoid type assertion by simply using slices to store event handler functions such as []func(*Hello). However, this may have memory implications I have not looked into (when we are NOT using pointers to a slice).

In any case, there will always be a concrete amount of handlers: Storing them via map would involve complexity and type assertion while saving initial memory compared to storing them via slices: Even using pointers, 62 event slices * 8 bytes = 496 bytes or .496 KB, before handlers have been added. Given that is bot is usually only created once (or with an uninitialized Handlers field which only takes 8 bytes), this is NOT a costly implementation.

The side effect however is that we must add an easy way for the user to ensure that there is a handlers object when it needs to be used. This can be done at initialization or in any other simple manner.

[switchupcb]

I have added the autogenerated Handlers struct, Handle function, and handle function. This may require some edits depending on the handling of certain events. Otherwise, the UI for the end user is even simpler:

// Add an event handler to the bot.
bot.Handle(disgo.FlagGatewayEventNameInteractionCreate, func(i disgo.InteractionCreate) {
	log.Printf("main called by %s", i.User.Username)
})

We will want to ensure the following prior to merging this request (after everything else for this PR is completed):

• Use correct imports during generation (easy fix likely handled outside of PR).
• Showcase how to remove a handler (using direct access index in examples).
• Session code event handling is consistent.
• Ensure user can instantiate a handler at Config.

Here is an example of how one may add a global handler. Keep in mind that this is not yet applicable for the first Hello handle prior to opening the session (because the session needs to be listening for events first).

// check if an event handler for hello events has been added to the bot.
if len(bot.Handlers.Hello) == 0 {
    // add the handler to the bot.
    bot.Handle(FlagGatewayEventNameHello, func(*Hello) {
        // add event handler code here.
    })
}
// otherwise, handler isn't added to the bot.

This code would be called when the session begins listening for events and a Hello is received.

[switchupcb]

The Handle function can implement automatic intent calculation by specifying which intents are required in the setup.go file for copygen events.

[switchupcb]

[switchupcb]

New Heartbeat Algorithm

[switchupcb]

note to self: add nlreturn (?)

[switchupcb]

Secrets (and environment secrets) can not be used by forked repositories unless certain conditions are granted.

https://stackoverflow.com/questions/58737785/github-actions-empty-env-secrets

[switchupcb]

Updated Documentation