JobViewServer specification proposal

Tue Apr 1 15:55:44 PDT 2008

On Tuesday 01 April 2008, A. Walton wrote:

first, the relevant bit to this thread:

> What really needs to happen, IMO, is an expansion of this existing
> standard 

this runs the risk of either making it clumsy for systems that wish to 
separate these displays or enforcing a unity in display here, since all 
messages (notifications and long running jobs) would be going through the 
same interfaces.

it would likely be easier to just have another dbus interface that provides 
for managing these jobs and allow the user interface to decide whether or not 
to aggregate them or not.

that doesn't mean it couldn't be part of the same spec (the galago spec 
already defines a number of dbus interfaces), but it would be good to keep 
the d-bus interfaces separate imho.

there's also a lot of flexibility that isn't really needed in both sides of 
this equation. so ... we'd end up with a rather bloated spec instead of two 
simple ones.

this really is something that should be handled in the implementation (e.g. 
aggregating the results of both into one UI), and not the specifications imo.

btw, to see what KDE is using right now, look at the two dbus xml files here:

	http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/jobs/

and now on to the galago spec:

> And it just so happens FD.O already has a specification for
> notifications [1], a daemon and client implementation, and it's well
> adopted code in the GNOME community (I can't speak for the KDE side of
> things).

the plasma project recently started working on a mechanism to export via d-bus 
notifications that are intended to be shown as popups via d-bus from knotify 
out to the UI via this spec, as well as creating a plasma based ui to display 
such notifications.

it's based somewhat on the org.freedesktop.Notifications.Notify spec, but 
there are points of the spec that we would like to improve on.

what we have works nicely, and if we can get the spec in order, then hopefully 
in the near future (e.g. 2008, either the july or dec release) kde 
notifications can be exported to the GNOME ui, and GNOME apps can use the the 
plasma notification area. yay!

so... to thread hi-jack this for a discussion of the galago spec (sorry!) a 
non-exhaustive list of areas where we'd like to improve the spec include:

Basic Design: http://www.galago-project.org/specs/notification/0.9/x81.html

Issue: it's not clearly described what the "notification server" is 
responsible for. it does say that it is optional, however.

Proposal: clarify the language to define the scope and purpsoe of the 
notification server more clearly. e.g.: "The server is responsible for  
displaying the notifications to the user in a device and use case appropriate 
manner. While the server may make decisions at to how and which notifications 
to actually display, it is not responsible for configuring user notification 
preferences for the client application."

Icons: http://www.galago-project.org/specs/notification/0.9/x207.html

Issue: the iibiiay format seems a bit overspecified.

Proposal: always use argb32 data.

Issue: this part of the spec seems generally underspecificied. there is no 
reference to how icons referenced by name are resolved (the theme and naming 
specs) to name one.

Proposal: remove this page entirely. all relevant information on icons can be 
found elsewhere in the spec. duplicating information in this way just begs 
for inconsistencies over time.

Urgency Levels: http://www.galago-project.org/specs/notification/0.9/x320.html

Issue: having low/normal/critical as the only options may be ok for the 
immediate, but room for likely future growth should be taken into 
consideration. as such, having this in a byte with the values Low=0, Normal=1 
and Critical=2 makes this very difficult.

Proposal: Distribute Low, Normal and Critical across a wider range, e.g. Low = 
0, Normal = 127, Critical = 255. this way new values can be added and 
implementations could still work with a simple less than comparison of 
urgency level.

Hints: http://www.galago-project.org/specs/notification/0.9/x344.html

Issue: desktop-entry contains the literal name of the .desktop file. for 
multiple versions of the same application coinstalled (e.g. a kde3 and a kde4 
version) this creates an ambiguity. 

Proposal: use the storage identifier that can uniquely identify the app; 
though i don't see that concept in the fd.o specs? perhaps that too needs to 
be added ... but it allows us to e.g. disambiguate kde3-kcalc from 
kde4-kcalc.

Issue: image_data seems a overspecified.

Proposal: always use argb32 data

Issue: sound-file ... we actually handle sound elsewhere in our events system. 
The spec says the sound is to be played "when the notification pops up." 
Well, there's no guarantee of a popup at all here.

Proposal: Separate sound from visual cues in the spec. There is no such strong 
linkage.

Issue: suppress-sound is superfluous?

Proposal: remove it from hints altogether. if the app is going to play its own 
sound, don't provide anything in sound-file.

Issue: no way to relate it to an application window, which is useful for 
taskbar or window effects

Proposal: add an opptional winId hint

Categories:

these seem a bit random. i'm sure they made all the sense in the world to the 
authors, but this section could use a lot of work. things like the 
distinctions between email/im/presence could use work, or how device 
notifications are not actually handled by notifications in all systems for 
user interaction reasons, etc. a number of fairly obvious categories are also 
just plain misisng. probably this is mostly due to simply not having more 
users of the notification system and could be worked out over time. it would 
be nice to note this in the spec and make the current list a bit more fluid.

i also wonder why it's using '.' as a separate rather than '-' as most of our 
other specs seem to.

the use of x-vendor.class.name seems unnecessary. if there's no consensus on 
the matter then either only one part will use it (and there's no threat of 
collision) or one has to ask themself if it really matters if the grouping 
semantics aren't agreed on. if "x-vendor" is kept, for conformance with other 
specs it should be "X-Product". see: 
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s08.html

D-BUS Protocol: http://www.galago-project.org/specs/notification/0.9/x408.html

org.freedesktop.Notifications.GetCapabilities

Issue: it's odd that the possible server capabilities are defined on this 
page, whereas all other such listings (categories, hints, etc) are defined on 
their own pages.

Proposal: Create a Server Capabilities page after section 8 Hints and move the 
listing there.

org.freedesktop.Notifications.Notify

Issue: app_icon is not necessarily appropriate for a given notification. it is 
defined as "The optional program icon of the calling application." the other 
option is to use the icon_data hint instead and ship raw data. there's also 
abiguities as to the related to icon_data, where this icon is defined, etc.

Proposal: "The name of the icon to show in association with the notification, 
such as the application icon. The icon name should be accessible via icon 
theme loading as defined in the freedesktop.org Icon Theme and Icon Naming 
specifications {link to urls}. Alternatively, image data may be passed via 
the icon_data hint {link to description of hint}.

9.2 Signals

do we really need these signals broadcast to all applications? esp when we get 
to long running jobs with updates, it makes sense to reply directly back to 
the calling object since traffic can get pretty high in both directions.

i'm probably missing things, but that's a good starting point for discussion.

(btw, i find it a bit cheeky to namespace a dbus interface in org.freedesktop 
when there has been essentially zero actual freedesktop.org processes put to 
it. interfaces should either start with cross project involvement from the 
start or namespace themselves to the project. any other approach risks 
poluting org.freedesktop needlessly.)

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

and add speed, total amount ("450 images", "300 Mb", "3 filters") ... there's 
more to it than immediately meets the eye, and a lot in the notification spec 
that is not overly relevant to job listings.

there's obvious similarities, but i'm not sure the similarities justify a 
unified spec.

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

.. and then get back a new ID that you then have to hold on to each time on 
the client side, essentially mapping an internal id to an external one that's 
constantly changing? and heaven forbid the replies should ever get out of 
order with sends (e.g. this would need to be synchronous). this seems very 
hackish. you don't want to replace anything, you want to be updating 
something.

> Of course, the current implementation of the notification-daemon is
> near useless; you can't hide/reject notifications from parties you're
> not interested in, you can't get a history of notifications,

this is all implementation side, of course, and not particularly interesting 
to the spec.

> and 
> there's no way for applications to get a list of other open
> notifications nor a specific notification

you mean specific to that app.. but then how would you control that? trust the 
app? sounds like a great way to open the door to leaking information from one 
app to another ...

> shame. These are all specific defects in the existing code and
> standard that are barriers to entry which are very easily overcome,
> it's just a matter of sitting down and doing the work.

well, i think this lists mostly defects in implementation which aren't 
particularly of interest here.

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

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080401/614da938/attachment-0001.pgp 