Thoughts on uiserver

[Rafael Fernández López]

Hi Ricard,

2007/1/15, Ricard Marxer Piñón <rmarxer at iua.upf.edu>:
> I have followed a bit the later development of the uiserver and have a
> few questions/thoughts:
>
> - should the uiserver still belong to KIO now that it handles Jobs other
> than input/output operations? other reasons apart from the history of it?

Well, that's not my decision :P. We have planned maybe moving it to
plasma, but I think the server itself should be on kio (kdelibs).

> - the uiserver clients (the apps that want to publish their jobs and job
> progresses) should publish the actions available for the given jobs
> using DBUS.  a job would the be a DBUS object implementing one or
> several DBUS interfaces, that can be predefined or defined on runtime.
> I think this is how Mathusalem does it and it allows for more
> interoperability.

Here there's something similar. All jobs on KDE (not on KDE4, but on
KDE history) are done with a KIO::file_copy(...) and so on. They will
notice the uiserver automatically if necessary.

There's another extra life on uiserver, you can create "virtual jobs",
for example when your program is computing some big amount of data,
show a progress that isn't really a KJob in any case.

> - all jobs should be pauseable, cancelable and/or stoppable.  These are
> common actions to all jobs and might be handled differently than other
> more specific actions.  This can be implemented as a base DBUS interface
> for every job:
>     + pauseable() means the job can be paused and resumed as long as the
> application that owns it is still running.
>     + cancelable() means the job can be cancelled.
>     + stoppable() means the job can be stopped and resumed even if the
> application that owns it is not running anymore.

Well, that's not true. You can't pause a going on burning cd/dvd. You
maybe wont like to pause some jobs. I think having some actions
predefined is bad in general. We should let jobs decide what they want
and what they dont want to do.

> - all jobs should have a common way to "ask for user input" and another
> way to "wait for user input".
>

Hmm, probably you're right. We should wait to see the needs of the
jobs on the uiserver, and see how far they get.

>
> longterm thoughts:
>
> - being able to publish trees of jobs (jobs waiting for other jobs to
> stop before they start or several jobs starting at the same time). (use
> case:  when a user selects several files to be copied, he wants to make
> the files to be copied in parallel or in series once the job has started.)

Have to think more about that. KGet does that right now. I think I can
implement this, but that will be later (as you say longterm) ;)

>
> I'm not sure if this is the place or the moment to post this, correct me
> if I'm wrong, please.

I really think never is late and never is so early. It is good to have
ideas from other people, it always helps myself to know what people
expects.

Bye and thanks,
Rafael Fernández López.