Re: schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Hi,

Is there a reason why this patch is marked as 'pending'?

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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?

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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?

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  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.

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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?

schedsvc: Add Task Scheduler service. Try 2.

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Alexandre Julliard  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?

schedsvc: Add Task Scheduler service. Try 2.

[Dmitry Timoshkov]

Alexandre Julliard  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.