JobViewServer specification proposal

[Rafael Fernández López]

Hi,

> What really needs to happen, IMO, is an expansion of this existing
> standard and code to allow it to be flexible enough to be used with
> very long running applications. Not a lot needs to change to make this
> happen either: to make the notification not expire until we want it
> to, set the expiration timeout to 0, a new hint needs to be added
> "progress", which indicates how far along a current job has progressed
> (obviously), the "categories" should really have some more generic
> "long running task" category, such as "Job", and the addition of a few
> methods to make it easier for application developers to update
> existing notifications such as GetNotification and ListNotifications.

IMHO they are for different purposes. Aaron posted the XML address in KDE 
repository which I will explain in detail this Friday probably, but there you 
can see that adding such information to the notification system would just 
overkill that spec.

The main idea is that the code that is on the libraries mainly would handle 
this. In our case, for example, KIO (what is used by all applications with 
I/O needs) will handle the calls to the kuiserver, but really, if you have a 
instant messaging application (say Gaim), and do a contact import, for 
example, and want to track that with a progress, it would take you a very 
little code for that.

> So then applications just need to be able to hold on to, or get hold
> of, the notification-related information and send notifications to
> update the current one when necessary. The standard facilitates this
> with the "Replaces ID", which I've found to be sufficient in the work
> towards this that I've done. With some further work, the existing
> libnotify client could handle these details.

I really think I don't want to spam libnotify with those messages...

> Perhaps my thoughts are just bending an existing standard way outside
> of its usefulness and I'm totally wrong, but I'd suggest taking a good
> read of this standard and seeing if you can really make it work. I
> started work on this last year, but I never followed through with it
> like I should have. This would be a good opportunity for reviving this
> standard and the code. I wouldn't mind working with you on this if
> you're interested in some help.

I really appreciate your comments and your ideas, but from my point of view 
the notification system should not enter in this tasks. The notification 
system is for a different purpose: "5 mails arrived", "A contact added you", 
but not for the progress itself.


Bye and thanks,
Rafael Fernández López

GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080402/45f31ea3/attachment.pgp