This repository has been archived by the owner on Apr 24, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy path_implementing.txt
108 lines (76 loc) · 2.56 KB
/
_implementing.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
// Copyright (c) 2020 Oliver Lenehan. All rights reserved. MIT license.
- [x] ServiceQueue: Locking resources
- [x] Comments
- [x] EventQueue
- [x] Comments
- [x] HTTPClient
- [ ] Comments
- [ ] WSClient
- [ ] Comments
- [ ] BucketPool : Map<Snowflake, Bucket>
- [ ] Comments
- [ ] DiscordCache: Map<Snowflake, Object>: Caches all objects inbound in discord.
- [ ] Comments
- [x] ClientContext: Programming Interface
=> All current information, acts as the internal client data controller
- [ ] Client: User Interface
Need a way to verify events/messages were sent and received.
An "Optimist" Message Set which stores the message, and deletes on confirmation of being received, this can wrap around EventQueue as Flow control e.g. EventQueue(millis).
----------------
Discord Objects:
Message
Channel
Guild
User
Other Objects:
Attachment
Colour
----------------
Implement tests for speed into certain classes.
Ideally need to test certain calls with a server pretending to be discord, sending premade responses. (long term)
----------------
WSClient
+ Sending payloads.
+ Receiving payloads.
identified a need to listen for different events depending on bot needs.
actually getting data
+ maintain 500ms+ gap between sent events (timed queue)
1. connecting
+ getting a gateway url (getGateway for non-sharded, getGatewayBot for sharded)
+ append gateway url params
+ receive HELLO and store heartbeat
+ sharded bots must wait five+ seconds between starting another gateway
2. heartbeating
+ send HEARTBEAT every heartbeat interval millis until closed or terminated.
+ if not ack'd before sending next, terminate with non-1000 error code, re-connect and attempt to resume (log error too).
3. identifying
+ send IDENTIFY with payload (this can pass in an initial discord presence)
+ receive READY EVENT, store session_id and latest sequence number
4. resuming
+ buffer new events while starting resume
+ wait for READY then send RESUME
+ wait for RESUMED event
+ playback buffered events
+ open listing for new
5. invalidated sessions
+ could not initialise IDENTIFY
+ could not resume
+ dropped active session
+ ACTIONS: see 'd' key, if true, it can be resumed
+ should wait around 5-6 seconds then retry
6. disconnections
+ action via event code and handle properly
data object:
FlowControlQueue
EventQueue
ObjectCache
a next version: sharding
+ a process per socket
? should all events be merged ?
+ a different api for merged events?
----------------
HTTP Client
+authenicate with header
+provide user agent
+snowflakes as identifiers
+rate limits