Many plugins for the SeAT ecosystem rely on prices to function properly. The following list contains the most notable ones:
- seat-srp
- seat-buyback
- seat-billing
- seat-alliance-industry
- seat-transport
- seat-fitting
Currently, all these plugin have their own way of getting prices. Many depend on the now shut-down evepraisal service, and some use the data provided by the SeAT core. The most important takeaway here is that all of these plugins work and behave differently.
- A recent example: After the evepraisal shutdown, some plugins stopped working
- Users are more likely to be confused because each plugin works differently
- A lot of code is duplicated across all these plugins, increasing the maintenance burden
- Some users might want to use a different type of price, e.g. buy instead of sell prices. There is also the potential for exotic price providers that value items by e.g. the time it takes to build them (this has been requested and implemented in seat-alliance-industry).
Implement a library plugin providing accurate price information to plugins. The implementation should be in a way that allows users to select a price source ('price provider') individually for each plugin/use case. This is basically what already exists and works well in seat-alliance-industry and seat-transport: In their settings there is a list of price providers the users can select for use in their plugins. Possible price providers are:
- evepraisal and clones
- https://janice.e-351.com/
- https://market.fuzzwork.co.uk/
- (sometimes inaccurate) ESI Prices currently used in SeAT
- Calculators for build cost
- Simply a table providing the value
- I'm sure there are endless possibilities
That being said, not all of them need to be implemented.
This will get technical!
- provide prices
- easy to integrate into existing plugins
- extensible, available price providers shouldn't be limited to the plugin, other plugins should be able to register more price providers.
- Price providers will need to have configuration associated with them. For example, this can be the market region, sell or buy prices or a value modifier. My experience from seat-transport and seat-alliance-industry tells me that it's not enough to have one set of options that works for all price providers, they will need to be configurable on a per price provider base.
- It should be possible to use multiple instances of the same price provider with different configurations at the same time
- You should be able to request prices for multiple items at once to reduce API calls for implementations that use APIs.
To achieve the goal of having multiple instances of the same price provider with different configurations at the same time, I suggest introducing two concepts: A price provider instance and a price provider implementation.
The price provider instance is a normal database model containing a reference to a price provider implementation and the configuration it needs. There will be a page to create price provider instances: Users can select an implementation and configure its settings. Once the instance is created, in the plugin settings users can select a price provider instance to use. When plugins need price data, they can load the model representing the price provider instance and ask for prices:
$price_provider_instance = PriceProviderInstances::find($my_price_provider_instance_id_selected_in_settings);
$prices = $price_provider_instance->getPrices($my_item_list);A price provider implementation is the code that actually loads price data. I imagine it as a class that implements an
interface containing a single method: getPrices($items, $configuration). There will be a way to register price
provider implementations, so they appear in the list of price provider implementations when creating a price
provider instance. Other plugins can extend the available price providers by registering their price provider
implementations too. I suggest doing configuration creation the same way it is handled in eveseat/notifications for
discord mentions.
- Always return the price for one item or take in an amount and return item price times amount?
- I tend to take in an amount, as it is not much more work to implement it, but potentially makes plugin integration simpler.
- Price provider registry: config or service container based?
- SeAT core mostly uses config
- Dow we want caching? If so, do it as plugin or leave it to the price provider implementations?
- Should we contribute this to the seat core instead of making it as a plugin?
- How do we want to move on? I can contribute the initial code required for the library plugin, but I need support from the maintainers for plugin integration.
- seat-billing needs prices as a database model. Unless other plugins need that too I'll find a way to solve it without having this in the library.