A mechanism should exist to allow the server to communicate service messages to the client

[Rick McBride]

When we have a scenario like "There is a bug in the client and we need to turn off existing clients until we can get them updated" or something similar, we currently are left with the kludge of inducing a Capabilities Mismatch, which while having the desired effect, tends to communicate zero useful information to the user.

Instead, we should have a mechanism wherein the client applet can display a server-defined message or set of messages informing the user of whatever relevant status information needs presenting

such as:
* Servers are Down while we re-fuel our combat wombats.
* You need to update your client.
* I'm standing directly behind you with a large trout preparing to swing it at your head.

OK Perhaps not the last one but the point is that it should be completely flexible and not at all dependent on anything hard-coded in teh client, be it message or status value.

This is a far more direct method of communicating service status related issues than email, forum, or even microblog, although all of those methods are important as well.

[Rick McBride (rmcbride)]

Also, we need to make sure such a mechanism cannot be exploited. We don't want people sending "Press the Reset button on your PC to continue" messages to all our users.

[Rick McBride (rmcbride)]

I would expect that the client would recieve these, and provide them to the client applet for display, in such a way that people on non-gnome platforms could easily implement message display in their equivalent applet.

This is me designing things without using boxes and squiglies.

[Roman Yepishev (rye)]

I would suggest to post such notifications on the web ui as well so that if something is wrong and is known to be wrong, then all pages on one.ubuntu.com will contain the header explaining the problem with the link to the bug report.
This may prevent the pile-up of duplicating bug reports, instead the person will see the notification on the web UI and calm down.

This is much like the IVR messages ISPs have that tell you "the problem is known and stop DoSing our call centers".

[Facundo Batista (facundo)]

<facundobatista> rmcbride, you want a generic service message, something that the server can initiate at any time? or with a message when an error occurs is ok?
<facundobatista> rmcbride, note that "protocol mismatch", particularly, is not an "error"
<rmcbride> facundobatista: that particular but was to allow us to convey service messages to the user, not necessarilyl errors
<facundobatista> rmcbride, ok
<facundobatista> rmcbride, so I'm removing this from the "to lucid" queue, as it's too late to change now the protocol
<rmcbride> facundobatista: OK. Sounds reasonable. That'll go in the day after Lucid, right ;D
<joshuahoover> rmcbride, facundobatista: so getting that messaging capability means changing the protocol to support it?
<facundobatista> joshuahoover, yes, we need a new "SERVICE_MESSAGE" message