schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov <dmitry at baikal.ru> writes:

> Alexandre Julliard <julliard at winehq.org> wrote:
>
>> >> > Well, I've been thinking of it, and a Wine session lifetime could be
>> >> > considered as a short-living Windows machine, with all the limitations.
>> >> > And there are a lot of various things that the task scheduler is able
>> >> > to do that I don't know how could be mapped say into cron for instance,
>> >> > like executing a COM handler, or supporting many kinds of triggers.
>> >> >
>> >> > There are many known use cases for the task scheduler like a task
>> >> > regularly checking for updates, or a task executed on user logon,
>> >> > or a task being executed on a network connection. For a list of
>> >> > various tasks you could check system32\tasks on any Vista+ system,
>> >> > there are pretty interesting examples in there.
>> >> 
>> >> I still think this needs more thought. Having triggers that only happen
>> >> while some other random Windows app is running doesn't strike me as
>> >> particularly useful.
>> >
>> > Well, that's how it's supposed to work actually, just like a scheduled
>> > cron job for instance.
>> 
>> A scheduled cron job runs no matter what the user is doing.
>
> That was just a plain analogy, I'm sure that there are other ways to
> describe the task scheduler activities.

The point is that if you schedule a task to run say on new network
connections, it's supposed to happen on all new connections. If it's a
Wine service, it would happen while the user is working with PowerPoint,
but not when he's working with LibreOffice. That doesn't make sense from
the user's standpoint.

>> >> I also don't think that this limited usefulness justifies the cost of
>> >> running the service in every single Wine session. It should be started
>> >> only when there are actually tasks to schedule.
>> >
>> > The service also has a role of global xml task definitions storage, so
>> > that any client application could add or query task status, or check
>> > and change the task running state, and that's impossible to do without
>> > a service, similar to the functionality provided by services.exe.
>> 
>> Sharing global state doesn't imply a service, there are many other
>> ways. That doesn't mean we can't have a service, but it doesn't justify
>> having it run in every Wine session.
>
> How the tasks I described already could be performed without a service?

There are plenty of ways to share global state, I'm sure you can think
of a few yourself. Again, I'm not saying we can't have a service at all;
but you need to find a way to not add extra cost to every single session
for the sake of a few rare cases.

-- 
Alexandre Julliard
julliard at winehq.org