pteropackages/pteroxide

A collection of efficient crate libraries for the Pterodactyl API

pteroxide's Issues

Wings API support

I think it would be great if Pteroxide could support all the major Pterodactyl APIs (that being application, client and Wings), and I don't believe that any other API wrapper or library has implemented this kind of coverage for Pterodactyl so this would be a good model/example for other wrappers/libraries.

Implementation specific details will be added soon.

Prioritize paginated responses

In other packages like PteroJS, Pytero and Ptero.cr, there are separate methods for accessing multiple results of a resource and a paginated result of a resource. This is bad design IMO, and Pteroxide should not follow those implementations. I think that having a paginated response object returned for endpoints that return multiple resources would be better, Pydactyl implements this really well. We can take advantage of the iterator traits in Rust to achieve this.

Caching crate

Having some kind of cache for endpoint resources is generally useful, and is even implemented in other packages like PteroJS. This would best fit as it's own crate though (likely pteroxide-cache), respecting the modularity of each package.

Mapping egg configuration files

Currently this is in place of the files field for the egg configuration object:

Pteroxide/pteroxide-models/src/application/egg.rs

Lines 33 to 37 in 19775e9

	/// Represents the inner configuration of an [`Egg`].
	#[derive(Clone, Debug, Deserialize, Eq, PartialEq, Serialize)]
	pub struct EggConfig {
	// FIXME: might not be able to implement this due to complexity
	// pub files: HashMap<String, EggConfigDescriptor>,

This is because the files object can contain nested objects containing string, number, boolean and object values – it's potentially recursive, and really hard to convey in Rust due to type unions not being a thing. One workaround could be a C-style union which is more like an object or named tuple with all the potential values, but implementation complexity may be a problem with that.

Client API support

The application and client APIs are the major / most important APIs in Pterodactyl that need to be supported for Pteroxide to be usable. This should include:

• Coverage of the whole client API
• A detailed permissions model
• A detailed files API model
• Websockets support
• Websocket cluster management

Crate documentation

The pteroxide-http and pteroxide-models crates are not really consistent in terms of documentation, and there are parts in both that don't follow the Rust standard for documenting crates. This will definitely require some work before making a major release.