Adding support for reading and modifying tasks

[poopsicles]

So yeah, I've moved this to another branch (I'll sync up the changes once #2 is resolved) but the goal of the ScheduleGetter struct is to be able to:

• Read tasks from a folder
• Modify tasks

Right now it just exposes IRegisteredTask so yeah it doesn't really fit in. Maybe I could take that returned value and somehow structure a Schedule from it?
And then provide avenues for "saving" this Schedule as opposed to "registering" it, or maybe registration can just delete any previous tasks with the same name.

What would you envision the design to be like ideally?

[mattrobineau]

I agree with your statements and believe that you are on the right track.

What would you envision the design to be like ideally?
The only goals I have for this crate is to abstract away the windows crate and provide lots of documentation.

The reason for this is that I find the windows documentation to be quite lacking if not non-existent. As a side note, I think the people working on the windows are doing a good job and have a TON of stuff to cover and understand that not everything can be documented or perfect on day 1 and I expect the situation to ameliorate over time.

Secondly, I had to spend lots of time reading the Microsoft documentation (linked in the README.md) which I think only had C++ examples which is not a language I use or have studied. I would like to save others from having to do this with this crate.

/background

As you mention, I think it is a good idea to use the Schedule struct represent new or existing Scheduled Task.

This PR has started to make me think that ScheduleBuilder should be refactored a little and maybe make a TaskScheduler struct which would have impls that allow for CRUD operations as well as registering scheduled tasks. For example (pseudo-ish code):

let ts: TaskScheduler = TaskScheduler::new();
let s: Schedule = ts.Get("SomeId");
s.Author = "Name"; // or s.Author("")
ts.Save(s);

let sb: ScheduleBuilder = ts.Create();
let new_sched: Schedule = sb.etc.etc...
ts,Register(new_sched);

What are your thoughts on this?

[mattrobineau]

Just a note here, target branch release/1.0 for this.

[poopsicles]

As you mention, I think it is a good idea to use the Schedule struct represent new or existing Scheduled Task.

This PR has started to make me think that ScheduleBuilder should be refactored a little and maybe make a TaskScheduler struct which would have impls that allow for CRUD operations as well as registering scheduled tasks.

Well, what if there's a base TaskScheduler that can either Get() an already existing task, or Create() a new one...why not just have it work with Schedules always then.

Like creating a task can look like this:

let ts: TaskScheduler = TaskScheduler::new();
let new_sch: Schedule = ts.Create();

new_sch
    .create_time()
    .author("Test dummy")?
    .description("Test Time Trigger")?
    ...
    .register()?

And modifying a task can be:

let existing_sch = ts.Get();
println!("{}", existing_sch.GetAuthor());

existing_sch
    .author("Test dummy")?
    .save()?

The reason ScheduleBuilder exists as I see it, is to make it easier to create a well-formed Schedule...but since we also want to edit them, doesn't it make sense to combine the two (and make maybe appropriate marker types so something like GetAuthor can't be called on a Schedule just being made?

Well, either that or make a new ScheduledTask type that is specifically for already existing tasks being modified.

[mattrobineau]

Well, what if there's a base TaskScheduler that can either Get() an already existing task, or Create() a new one...why not just have it work with Schedules always then.

Yes, I think we are saying the same thing (almost). I'm ok with the existing_sch approach where the Schedule struct can take care of changing and then saving the modified properties to the Windows Task Scheduler. However, lets not merge the builder with the Schedule struct and keep those separate.

The TaskScheduler base that can get or give a user a ScheduleBuilder is a useful idea. Recent changes to the way schedule builder works is that it now requires the user to pass in a ComRuntime object.

   let com = ComRuntime::new()?;
   let builder: ScheduleBuilder<Base> = ScheduleBuilder::new(&com).unwrap();

This could all be handled by TaskScheduler struct:

pub struct TaskScheduler {
 com: ComRuntime
  .. stuff ..
}
impl TaskScheduler {
  new() -> Self {
     Self.com = ComRuntime::new().unwrap();
    .. stuff ..
  }

  create() -> ScheduleBuilder<Base> {
    .. stuff ..
    ScheduleBuilder::new(self.com.clone()).unwrap()
 }
}

Note that the Schedule will also need to keep a reference to the ComRuntime object.