Thoughts on uiserver

[Rafael Fernández López]

2007/1/16, Ricard Marxer Piñón <rmarxer at iua.upf.edu>:
> 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).

This is what is happening. Look at job.cpp, and at jobuidelegate.cpp.
When a KIO::Job is created, it is "signaled" to the uiserver through
dbus (so some day we will can give support to the mathusalem system
from gnome desktop).

Any application can create those "virtual jobs", by going directly
through dbus to the uiserver. The "protocol" is already done, but it
isn't new, it was there with kdcop too. You can find the specification
at http://websvn.kde.org/trunk/KDE/kdelibs/kio/kio/org.kde.KIO.UIServer.xml?rev=624294&view=markup.

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

This is already done this way. Look at the xml specification of the
kuiserver. ;)

> 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)

There is no observer server. The observer is on the "app side", so
each instance will be pointing to a different observer class. The
observer will call uiserver (independent app) through dbus calls.

> - Is it possible to define dbus interfaces without any applications
> running? (for example the default interfaces I mentioned like
> PauseableJob,...)

Hm don't get you here.

> - 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)

This sounds very Java's :). Well, it can be done I think, but I still
bet for actions instead of predefined "states" for jobs. I will
implement a new addAction method in addittion to the existing one, to
provide an enum list of usual actions (cancel, pause, ...).

> 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.
>
>
> PS: Have you thought of calling the server Jobserver (or would it sound
> too Java)??
>

I'm not imaginative with names at all. Something with a leading "K"
should be better...

Bye,
Rafael Fernández López.