Hi,
Is there a reason why this patch is marked as 'pending'?
Dmitry Timoshkov dmitry@baikal.ru writes:
Hi,
Is there a reason why this patch is marked as 'pending'?
It needs a more convincing argument. For instance, why do you need this service, where does the interface definition come from, why does it need a global header, why does the service need to run constantly, etc.
Alexandre Julliard julliard@winehq.org wrote:
It needs a more convincing argument. For instance, why do you need this service
I have an application that depends on this.
where does the interface definition come from,
It's documented in MSDN: http://msdn.microsoft.com/en-us/library/cc248435.aspx
why does it need a global header
If you mean a global .idl then it follows what's already present for the services.exe service since it's also a service exporting public RPC API.
why does the service need to run constantly, etc.
Task scheduler service needs to run constantly because it may need to handle various events like user login/logout, tasks starting when the system becomes idle, network connects/disconnects, tasks starting at any specified date and time, and many other types of triggers.
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
It needs a more convincing argument. For instance, why do you need this service
I have an application that depends on this.
Depends how?
where does the interface definition come from,
It's documented in MSDN: http://msdn.microsoft.com/en-us/library/cc248435.aspx
why does it need a global header
If you mean a global .idl then it follows what's already present for the services.exe service since it's also a service exporting public RPC API.
If it's not used outside of the dll there's no reason to have a global header.
why does the service need to run constantly, etc.
Task scheduler service needs to run constantly because it may need to handle various events like user login/logout, tasks starting when the system becomes idle, network connects/disconnects, tasks starting at any specified date and time, and many other types of triggers.
That's not very convincing. If we really want that sort of support it would have to be integrated with the OS, it can't be done from a Wine service.
Alexandre Julliard julliard@winehq.org wrote:
It needs a more convincing argument. For instance, why do you need this service
I have an application that depends on this.
Depends how?
At installation time it schedules a task which should be executed when the installer exits, also it creates a task which checks for updates.
where does the interface definition come from,
It's documented in MSDN: http://msdn.microsoft.com/en-us/library/cc248435.aspx
why does it need a global header
If you mean a global .idl then it follows what's already present for the services.exe service since it's also a service exporting public RPC API.
If it's not used outside of the dll there's no reason to have a global header.
I'm planning to use it from taskschd.dll, and have already started this.
why does the service need to run constantly, etc.
Task scheduler service needs to run constantly because it may need to handle various events like user login/logout, tasks starting when the system becomes idle, network connects/disconnects, tasks starting at any specified date and time, and many other types of triggers.
That's not very convincing. If we really want that sort of support it would have to be integrated with the OS, it can't be done from a Wine service.
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.
Dmitry Timoshkov dmitry@baikal.ru writes:
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.
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.
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.
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.
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.
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.
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.
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?
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.
Alexandre Julliard julliard@winehq.org wrote:
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.
Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running.
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
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.
Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running.
If there are scheduled tasks then it's OK for the service to be running always; but as long as there aren't, it should be started on-demand.
Alexandre Julliard julliard@winehq.org wrote:
Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running.
If there are scheduled tasks then it's OK for the service to be running always; but as long as there aren't, it should be started on-demand.
So I would implement it like this: the service would be always started on Wine boot, it would then load the xml task definitions and if there is no anything would exit right away. Then the service would be started by taskschd.dll if ITaskService::Connect() can't connect to an existing service instance. Does this sound acceptable?
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running.
If there are scheduled tasks then it's OK for the service to be running always; but as long as there aren't, it should be started on-demand.
So I would implement it like this: the service would be always started on Wine boot, it would then load the xml task definitions and if there is no anything would exit right away. Then the service would be started by taskschd.dll if ITaskService::Connect() can't connect to an existing service instance. Does this sound acceptable?
No, having it start always defeats the whole point. Just mark it auto-start once a task is added.
Alexandre Julliard julliard@winehq.org wrote:
Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running.
If there are scheduled tasks then it's OK for the service to be running always; but as long as there aren't, it should be started on-demand.
So I would implement it like this: the service would be always started on Wine boot, it would then load the xml task definitions and if there is no anything would exit right away. Then the service would be started by taskschd.dll if ITaskService::Connect() can't connect to an existing service instance. Does this sound acceptable?
No, having it start always defeats the whole point. Just mark it auto-start once a task is added.
In 'Try 3' I tried to address all the discussed things, is there anything else that prevents this patch from being accepted?
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
It needs a more convincing argument. For instance, why do you need this service
I have an application that depends on this.
Depends how?
At installation time it schedules a task which should be executed when the installer exits, also it creates a task which checks for updates.
Does it really call the service directly, or does it go through taskschd.dll?
Alexandre Julliard julliard@winehq.org wrote:
It needs a more convincing argument. For instance, why do you need this service
I have an application that depends on this.
Depends how?
At installation time it schedules a task which should be executed when the installer exits, also it creates a task which checks for updates.
Does it really call the service directly, or does it go through taskschd.dll?
It does this using taskschd.dll COM APIs, but the scheduled tasks are all separate processes.
-
Alexandre Julliard -
Dmitry Timoshkov