Setting Times
Once one or more datasets have been requested, the creator has a lot of control over setting the expected time when the data should be ready. There are two types of expected times; a default batch time and custom dataset times. The default batch time applies to any dataset that does not have a custom time set, and creators should set one any time a request batch doesn’t require a custom start time for all datasets in the batch, with the exception of when most dataset start times are not known to prevent datasets opening for data too early. The creator having the ability to alter the expected times is a result of them being set as the initial controller. The creator can give up these abilities to another account, however, upon which the other account becomes the controller.
This feature is more geared towards ensuring flexibility for developing on top of the ODO because it would allow one contract or EOA (externally-owned account) to request the data, while a different contract could handle logic surrounding the timing. As an example, a tournament or match contract could activate a configured request once the conditions for beginning the tournament or match have been met.
The options for setting times are as follows.
1. Set Default Batch Time on Configuration
The simplest case for setting the default batch time is if it’s known at configuration time. This allows the time to be set with the initial configuration and saves a transaction.
2. Set Custom Dataset Time After Deployment (ODTimeKeeper)
If a default batch time was not and has not been not set, then each dataset’s time can be set individually. By passing the contract a list of datasets and start times, full control exists over setting the dataset times.
3. Override The Batch Time (ODTimeKeeper)
If a default batch time has already been set, then the same control still exists and each dataset’s time can be set individually by overriding the batch time. Again, by passing the contract a list of datasets and start times, full control exists over setting the times the data is expected to be ready for the dataset.
4. Set Default Batch Time After Deployment (ODTimeKeeper)
If a default batch time was not set, then the controller can still set a default time afterwards for any remaining datasets. Even if some of the datasets in a request batch have been completed and paid out, a default time can still be set for any that have yet to have a start time assigned.
5. Change The Default Batch Time (ODTimeKeeper)
If a default batch has already been set, then the controller might need to change the time. This is possible up until data has been provided for any dataset using the default batch time.
6. Change A Custom Dataset Time (ODTimeKeeper)
If a dataset’s custom time has been set, then the controller might need to change the time. This is possible up until data has been provided for the specific dataset only.
This suite of abilities allows the creator/controller to cheaply set a default or have complete control over custom times. One thing that is important for endorsers to consider is that the expected time can change after staking but before providing even begins. This case is covered in the Algorithms sections.
The decision to wait until data is provided rather than earlier, such as when staking starts, is in case something happens to push the expected time very close to when data is expected. For example, there could be a dataset based on the match statistics from a PC game. A user might stake ten minutes before the end of the match, when the venue loses power resulting in the match being postponed. As long as the fate of the staked user is considered, postponing the expected time for the data should be allowed in this case. This case has been handled in a way that it benefits the staked user and its handling is covered in the Algorithms section.
Last updated