Thoughts on uiserver

[Ricard Marxer Piñón]

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

Thanks for pointing out to the spec.  And mostly for taking the time to 
explain all this.  I hope I'm not intruding too much.  I won't be 
disturbing you with long general emails anymore.  Will just try to help 
with specific points.
>
>> 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. ;)
Good, so my thoughts weren't so far!
>
>> 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.
Now I understand (I think)!  Maybe the independent KDE apps will use 
KJob instead of direct calls to dbus.
>
>> - 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.
No problem. It wasn't important anyway.
>
>> - 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, ...).
Well, I still think some states are necessary.  I think the user will 
want to know by watching the uiserver applet whether a job is running, 
not started, paused, finished, finished unexpectedly or canceled.  Maybe 
just a simple thing like:

myJob->setState(KJob::NotStarted)
myJob->setState(KJob::Paused)
...

If a job cannot be paused, then it will never be in this state.  The 
enum with the usual actions is really great, that gives flexibility for 
the future.   That way someday the uiserver applet will allow the user 
to select a few jobs and pause them all with one button click, etc.

>
>> 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...
It was just a dumb joke.
>
> Bye,
> Rafael Fernández López.
>


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