INDI drivers were not designed to meet real-time constraints. I think even before discussing a local scheduler, find if you can truly develop an INDI driver that could meet such demands.
Hmm.. Actually I have not the need to schedule by itself, but to know if I can get accurate timing informations about captures in detectors and exposures in CCDs.
I have to take a capture from different detectors "almost" at the same time, so scheduling with a precise timestamp seemed to be my solution.
Fortunately the captures may be one- seconds or more, and got the initial timestamp I can re-align the frames after.
I realize that it's not common and not much constructive the argument of this thread.
By the way, Thank you all.
It seems syncing an exposure to a specific timestamp could be a good feature though. So perhaps you should reformat your wish with this intent if you have a need for it.
I'm reading your description, and found maybe something closer to your idea:
Basically in IsNewNumber there's maybe the need of a usleep() before StartExposure().
Is this what you meant?
I suppose so: the feature would actually be a regular exposure, except longer because of a UTC timestamp at which to start.
That timestamp would be set as a property by the client, sanitized by the driver and eventually reset once the exposure starts.
The driver would calculate the incurred delay before the actual exposure, and poll with adequate precision until the exposure has to be started.
Aborting would still cancel the exposure be it waiting to start or running the hardware capture.
Only future timestamps would be considered as valid start times. This would allow simple initialization to the start of epoch, and avoids the reset requirement.
I believe this should only impact INDI::CCD. An extension to this change would be for that high-level interface to be able to determine the delay between the start request it makes and the actual start of the hardware process. But this could be thought about in a more generic way: some sort of hardware backlash.
Implementation is restricted to one driver. Side-effects are relatively small as the concept of exposure was not modified. If a client doesn't use the delayed exposure feature, then the driver works exactly the same as before. The driver is however probably more sensitive to signals and system configuration.
I don't think INDI::CCD should change to cater to this. Maybe child classes of INDI::CCD or INDI::Detector can define properties for real-time capture and synchronization, and then you need clients to understand these properties and manage them accordingly.