Closed jorgearj closed 11 years ago
jorgearj
commented
11 years ago Couldn't we leave this task to the price "post-processing"?
We have the pricing module with all the components prices, than the user selects wich components he wants and a price is calculated based on the model. But this task is ensured outside the Linked-USDL. Somehow similar to the idea for the Amazon EC2 Spot Instances.
jorgearj
commented
11 years ago After experimenting with Heroku UseCase i believe that the configuration variables are not necessary. In my opinion the only example where these variables could be of use is for specifying particular option from the user side.
I.E: If a user wants to contrat 2 databases one Crane and another Ika (both Heroku databases). The final price is based on these two databases. The configuration variables would be useful for specifying the options.
However in my opinion the Pricing model should not be responsible for giving a final price (if the price is not static) but rather allow its later calculation. With this being said i believe that providing the service pricing model is enough. Later on an application or other interface should be responsible for instantiating the model, especially the Usage Variables and the amount of offerings/services contracted.
jorgearj
commented
11 years ago Configurations made by the user should be outside the pricing model. With the functions and usage variables we can give a model for the price calculation that should be enough for the final price.
Ex: if a user wants 5 Heroku Crane Databases that cost $50 each, it it easy to calculate the final price since the model has a price for one unit. However this calculus should be provided outside the price model.
They were originally intended for options that the user could select, and specific instantiation for the price model. Ex: Wich heroku database the user wants to use.
Do we really need these kind of variables?