http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/software-upgrade-required-35100

It'd be nice to accompany this with stuff in the details dictionary in <http://telepathy.freedesktop.org/spec/Connection.html#Signal:ConnectionError> — for instance, a URL, maybe the human-readable message from the server, etc.

It follows that we could also use a D-Bus error name meaning “you need to upgrade”.

I totally misread the commit. This already is a D-Bus error. My mistake.

So, better review comment on top of the above remark about defining some standard details for UIs: it might be nice to document which Connection_Status_Reason should be used to correspond to this.

Created attachment 44231 [details] [review]
Add EmergencyCallsNotSupported error

Comment on attachment 44231 [details] [review]
Add EmergencyCallsNotSupported error

sorry, wrong bug :/

Created attachment 44232 [details] [review]
Add EmergencyCallsNotSupported error

Comment on attachment 44232 [details] [review]
Add EmergencyCallsNotSupported error

what is wrong with me?

Apparently tp:error names need to be separated with spaces, rather than camel-cased, otherwise you'll end up with TP_ERROR_SOFTWAREUPGRADEREQUIRED instead of TP_ERROR_SOFTWARE_UPGRADE_REQUIRED

(In reply to comment #3)
 
> So, better review comment on top of the above remark about defining some
> standard details for UIs: it might be nice to document which
> Connection_Status_Reason should be used to correspond to this.

Added Connection_Status_Reason.

I'm not sure what standard details we might include. There is already the non-translatable debug-message. We could try and include an (as) of package names, but I don't see how we could do that in a portable way. I suppose it could be presented as a list of binaries/libraries that needed upgrading.

e.g.
upgrade-required = { "telepathy-rakia", "libsofiasip.so.0" }

And let the package manager figure out what packages provides those.

(In reply to comment #8)
> Apparently tp:error names need to be separated with spaces, rather than
> camel-cased, otherwise you'll end up with TP_ERROR_SOFTWAREUPGRADEREQUIRED
> instead of TP_ERROR_SOFTWARE_UPGRADE_REQUIRED

Fixed.

(In reply to comment #9)

> I'm not sure what standard details we might include. There is already the
> non-translatable debug-message. We could try and include an (as) of package
> names, but I don't see how we could do that in a portable way. I suppose it
> could be presented as a list of binaries/libraries that needed upgrading.
> 
> e.g.
> upgrade-required = { "telepathy-rakia", "libsofiasip.so.0" }
> 
> And let the package manager figure out what packages provides those.

Wondering how you would express python modules... papyon.py, python:papyon ?

Perhaps this isn't even worth it. The client can see what CM failed and could look to see if there's an upgrade of that CM and/or its dependencies available.

(In reply to comment #10)
> (In reply to comment #9)
> 
> > I'm not sure what standard details we might include. There is already the
> > non-translatable debug-message. We could try and include an (as) of package
> > names, but I don't see how we could do that in a portable way. I suppose it
> > could be presented as a list of binaries/libraries that needed upgrading.

> Perhaps this isn't even worth it. The client can see what CM failed and could
> look to see if there's an upgrade of that CM and/or its dependencies available.

I don't think it's worth it. The initial implementation in empathy will probably just be to report this to the user in a nice way and optionally have a button to start the package manager and have it check for any updates. If we want to go a step further we can indeed map protocol/cm name to packages and specially ask/check for updates of those (or its dependencies)..

This is vaguely related to the idea that empathy's account UI should show all protocols we might potentially support and call a package manager if the user selects one we don't have a CM installed for (like gstreamer can do for plugin installation)

Merged, thanks!.  A fresh spec has just released and a new telepathy-glib
release should be out soon