kuiserver future (to gui or not to gui)

[Aaron J. Seigo]

On February 22, 2007, Thiago Macieira wrote:
> Aaron J. Seigo wrote:
> >and just for giggles: i don't think this was possible with dcop at all.
> > so for people who were wondering if we'd actually get something more
> > with d-bus: voila!
>
> The only problem is the transfer of state: what happens if Plasma takes
> over uiserver tasks but there is already a progress bar being shown?

this can also happen anytime something bad happens with uiserver. e.g. where 
it to be accidently killed or, heaven forbid, crash...

two options that i see:

- say we don't care and that's just an inconsistency we'd have to live with
- make it so that communicatation is two-way so when a jobID appears that the 
visualization (kuiserver, a plasmoid, a cli app, whatever) doesn't know about

the latter is obviously the preferred =) right now we have the appServiceName 
only in the newJob call. we need this to be able to query the app in the case 
where we don't know about the jobID we just got an update for.

if the jobID contained the appServiceName, e.g. appServiceName::NumericalID, 
we could use that to figure out what the app we should call is. or we could 
just send the appServiceName with every method in addition to the job id. 
either way, to guarantee consistency we need the appServiceName.

that way the code can be like this pseudocode:

handleJob jobMessage
	if jobMessage.id not in knownJobs
		request resend of newJob from jobMessage.appServiceName
	else
		update knowJobs[jobMessage.id]


-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070222/2a0d692d/attachment.sig>