Thoughts on uiserver

[Ricard Marxer Piñón]

Rafael Fernández López wrote:
> 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.
>

Maybe I didn't explain myself well.  Second attempt.

I see this in a more general way, and I'm more trying to address the 
issue of general jobs (what you refer to as "virtual jobs").
I think a new protocol and a KDE implementation of such protocol could 
replace the current KIO:Jobs (or maybe complement them).

The idea is that any application must be capable of publish a job (e.g. 
"when your program is computing some big amount of data") he is doing 
and an interface for controlling this job remotely (e.g. from a 
centralized application or applet).  In order to do so a simple protocol 
is designed over DBUS, and in order to make use of this protocol simple 
for KDE application developers a client lib is written in kdebase.  This 
library would make it easy to create a job and publish it's interface 
and signaling (this is what your KJob class).  And the KIO processes 
would just have to create KJobs instead of KIO:Jobs (there has been a 
discussion about this and I agree with the conclusions).

I know that inventing a protocol from scratch is a lot of work, but for 
KDE developers this protocol can be more or less invisible (and then 
flexible and changeable), while the KJob class shouldn't change so much.

I think you did quite a good job with KJob (nice phrase).  But I have 
some worries if it could fit well with an evolution of the protocol 
behind, and since the interface is still under development it's a good 
moment to post my worries.
I have been thinking a little bit about the protocol behind.  And this 
is how I see it (could KJobs cope with it? if not, maybe the protocol is 
not good):

THE CLIENT (KJob):

- when a Job is created a dbus signal is sent and one of the arguments 
is the dbus interfaces of this Job.
    + I chose a signal because the fact of publishing a Job and exposing 
its interface is a many to many communication.  I believe its a many to 
many communication because there are several different ways of showing 
and controlling Jobs (from a UI point of view).  One could be the window 
with progress bars (a Job Progressbar applet) you should and another one 
could be a time line where you could schedule jobs (imagine being able 
to have a movie playing, published as a job, and in the Job Timeline 
applet add a shutdown action when the movie finishes, or having a file 
downloading and at the end schedule a burn to CD job).  Well the fact is 
that both applets should be able to run independently at the same time, 
and listening to these signals.

- the dbus interfaces of this Job can be created using KJob (exposing 
slots thanks to Qt love) or some that already exist (such as 
PauseableJob (some Jobs, like CDROM burning will not have this 
interface), StoppableJob, CancelabeJob).
    + When I mentioned in my last email that all Jobs could be 
pauseable(), I meant that being pauseable or not is a property belonging 
to all jobs (CDROM burning being not pauseable() and some file downloads 
yes).  Having this and some few other properties common to all jobs 
allows for some really nice interaction by the user (like pausing all 
pauseable jobs, or having by default a stop all stoppable jobs on 
computer shutdown and a question whether to cancel or not non stoppable 
jobs).
    + But I understand your desire of having actions general, that's why 
I propose doing it by dbus interfaces, in this way it's up to the 
application developpers to create their own or use default or predefined 
ones, and to the Job applet (server) developers to created special 
delegates for these dbus interfaces.

- when a Job changes state (pauses, stops, cancels, progresses, 
estimated times, changes its dbus interfaces, asking for user input, 
waiting for user input,...) a signal is sent.

THE SERVER (Observer or the Plasma applet):

- it listens to signals of created Jobs, Job state changes and it 
creates it's proxy objects and it's views and delegates on it's own way 
(a progress bar, a timeline,...)


Well, I hope with this explanation I made myself a bit more clear.  I 
don't really know the inner workings of how it is right now, but I think 
it's not far from this.  I think the fact of having a dbus protocol 
independent of the client and servers implementation makes it easier to 
extend to non-KDE apps and make it more flexible for the long run.

Some questions I don't know how to answer related this design:
- Are dbus signals much less performant than the client-server direct 
communication? (for example is much better to have only one Observer 
server with a JobServer)
- Is it possible to define dbus interfaces without any applications 
running? (for example the default interfaces I mentioned like 
PauseableJob,...)
- Is it possible to define inheritences on dbus interfaces? (for example 
a FileTransferJob could inherit from PauseableJob, StoppableJob,...)
- Can the applications that are launched after a dbus signal get that 
signal in someway? (for example if a Job has been created before the 
server has started)

After all this talk, I must say, that I'm in no position to ask for 
things, since I'm not really helping with the development.   So this is 
more of a brainstorm and ideas sharing than anything else.  When I get 
the energy I'll set up the KDE development environment setup and help 
you with your work.

Thanks for reading,
ricard

PS: Have you thought of calling the server Jobserver (or would it sound 
too Java)??


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.