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

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`

TheDiscordClient would then have 2 internal classes:RestManager andShardManager, 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 AbstractionsDiscordClient -> RestManager -> RestRatelimiter -> Deserializer -> RestClientGateway AbstractionsDiscordClient -> 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.

Related serialization task details

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 onDiscordClient

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

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 usingDiscordRestClient, 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 usingRestClient#CreateGuildChannelAsync to create a voice channel to avoid usingDiscordGuild#CreateChannelAsync because it requires me to supplyDiscordChannel as a parent.RestClient function gives me the way to avoid getting a wholeDiscordChannel instance just to supply an id for parent.
I think the suitable changes to this is to either makeRestManager 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

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.

privateasyncTaskLog(DiscordEventArgsargs,stringmessage){if(args.User==Client.CurrentUser)return;awaitLogChannel.SendMessageAsync(message);}

The only thing DiscordEventArgs has is a Handled property.

I don't how specifically this would be implemented, but it would be nice to be able to returnTask<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 fromBase​Command​Module, ex.public virtual Task AfterExecutionAsync<T>(CommandContext ctx, T value) whereT is the type of the value returned from the command andvalue is the return value itself, or alternativelypublic virtual Task AfterExecutionAsync(CommandContext ctx, object value) if calls to dynamically generated generic methods using reflection are to be avoided.

Example usage:

publicsealedclassCommands:BaseCommandModule{publicoverrideasyncTaskAfterExecutionAsync<T>(CommandContextctx,Tvalue){if(valueisstringstr)awaitctx.RespondAsync(str);}// Alternative versionpublicoverrideasyncTaskAfterExecutionAsync(CommandContextctx,objectvalue){if(valueisstringstr)awaitctx.RespondAsync(str);}[Command]publicasyncTask<string>ExampleCommand(CommandContextctx){return"Success";}}

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 anddescription are now strings, and localized strings are now stored inname_localizations anddescription_localizations
• /channels/<channel_id>/threads/active has been removed
• Existing attachments must be specified whenPATCHing 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 theX-Audit-Log-Reason header.
• Message routes acceptembeds rather thanembed
• Requests to v10 and higher will no longer be supported ondiscordapp.com