Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@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.