V5 Design

[Neuheit]

Discussion hub for the upcoming V5 rewrite

[Neuheit]

Related task board: https://github.com/DSharpPlus/DSharpPlus/projects/5

[Naamloos]

Taken directly from Discord by @Neuheit:

Hello DSharpPlus users!

As you may have seen I have started to work on a prototype for the V5 version of the lib, I have a long way to go but here is what I am thinking so far

- Remove `DiscordRestClient` and move all rest methods to the `DiscordClient`
- Remove `DiscordShardedClient` and have sharding be handled internally by the `DiscordClient`
- Remove `DiscordWebhookClient` (still debating this)
- Remove `BaseDiscordClient` and move methods/properties to `DiscordClient`

The DiscordClient would then have 2 internal classes: RestManager and ShardManager, each would contain their own ratelimiters, serializers, and request clients (WS, REST). The ShardManager would also have a cache manager that users can implement for increased control over their cache and to even have stateless bots. A greater emphasis will be placed on keeping entities and layers doing only what they should be doing (i.e. not making more requests than needed, not caching rest entities, and having little to no abstraction leakage)

Here's a potential look at the abstraction layers:

REST Abstractions
DiscordClient -> RestManager -> RestRatelimiter -> Deserializer -> RestClient

Gateway Abstractions
DiscordClient -> ShardManager -> ShardRatelimiter -> Shard -> Deserializer -> WebSocket

We will also be rewriting some of the extensions (namely interactivity, commandsnext, and also implementing a slash command service finally).
Entity design will also have to be reworked along with implementing a new serializer (not sure how these will work yet)

Let me know your thoughts on all of these, nothing here is set in stone however I personally feel this is the best approach.

[Neuheit]

Related serialization task details

[Neuheit]

Current Tasklist:

• Implement internal interfaces? (IRatelimiter, IManager, etc)

REST (RestManager)

• Implement RestManager API methods
• Implement RestManager ratelimiter
• Implement Rest serialization
• Implement raw (non-entity parameter) REST methods on DiscordClient

Sharding (ShardManager)

• Handle automatic and custom sharding internally via ShardManager
• Implement custom and inheritable cache interface that users can implement
• Implement shard ratelimiter
• Implement shard class
• Rewrite websocketclient class?
• Implement shard serializer

Serialization

• Details go here...

Entities

• TBD

Extensions

• TBD

[feelingnothing]

I'm not sure how it'd be possible to send api requests without having a object of any sort. In some cases I don't need the whole channel instance the sole purpose for is to just to send a message in it. My solution is using DiscordRestClient, but these changes blocks any static-like actions with API. For example I implemented voice lobbies where you can join a "create lobby" channel and bot makes voice channel for you and moves you there. When I'm creating a guild voice channel I'm using RestClient#CreateGuildChannelAsync to create a voice channel to avoid using DiscordGuild#CreateChannelAsync because it requires me to supply DiscordChannel as a parent. RestClient function gives me the way to avoid getting a whole DiscordChannel instance just to supply an id for parent.
I think the suitable changes to this is to either make RestManager public, or provide a way to use object's id to create a voice channel or send a message into a channel
If you did not understand some parts feel free to ask me questions, my english skills aren't that great

[Neuheit]

It is planned to have public rest methods (either in the DiscordClient or RestManager) take just ulongs rather than full entity types as parameters.

[Shadowblitz16]

I don't know if anybody else has this issue but there is no abstract EventArgs to allow users to get information about the message.
These are things like..
User,
Channel,
Guild,
Roles,
Embeds,
Permissions,
Etc..

The list goes on and on.
I ran into this when trying to pass abstract message data.

        private async Task Log(DiscordEventArgs args, string message)
        {
            if (args.User == Client.CurrentUser) return;
            await LogChannel.SendMessageAsync(message);
        }

The only thing DiscordEventArgs has is a Handled property.

[ProfDoof]

This is because you are using the base DiscordEventArgs class instead of the appropriate event args class for that event. Gimme a minute and I'll send a link to one of them.

[ProfDoof]

https://dsharpplus.github.io/api/DSharpPlus.EventArgs.MessageCreateEventArgs.html

[thinker227]

I don't how specifically this would be implemented, but it would be nice to be able to return Task<T> from CommandsNext commands and be able to access the return value from a post-execution context. A possible candidate for this would be an overridable method from Base​Command​Module, ex. public virtual Task AfterExecutionAsync<T>(CommandContext ctx, T value) where T is the type of the value returned from the command and value is the return value itself, or alternatively public virtual Task AfterExecutionAsync(CommandContext ctx, object value) if calls to dynamically generated generic methods using reflection are to be avoided.

Example usage:

public sealed class Commands : BaseCommandModule {
    public override async Task AfterExecutionAsync<T>(CommandContext ctx, T value) {
        if (value is string str)
            await ctx.RespondAsync(str);
    }
    
    // Alternative version
    public override async Task AfterExecutionAsync(CommandContext ctx, object value) {
        if (value is string str)
            await ctx.RespondAsync(str);
    }

    [Command]
    public async Task<string> ExampleCommand(CommandContext ctx) {
        return "Success";
    }
}

[dongle-the-gadget]

Discord now released their API v10.

Changes:

• API v10 now enforces message content intent (1 << 15)
• [ALL VERSIONS] application.summary now returns an empty string. This field will be removed in v11
• Achievement localization format has changed. name and description are now strings, and localized strings are now stored in name_localizations and description_localizations
• /channels/<channel_id>/threads/active has been removed
• Existing attachments must be specified when PATCHing messages with new attachments. Any attachments not specified will be removed and replaced with the specified list
• Audit log reason as a body/query parameter is no longer supported, and you should instead use the X-Audit-Log-Reason header.
• Message routes accept embeds rather than embed
• Requests to v10 and higher will no longer be supported on discordapp.com