Merge lp:~ssweeny/location-service/delayed-providers.15.04 into lp:location-service/15.04
| Status: | Approved |
|---|---|
| Approved by: | Thomas Voß on 2015-10-28 |
| Approved revision: | 201 |
| Proposed branch: | lp:~ssweeny/location-service/delayed-providers.15.04 |
| Merge into: | lp:location-service/15.04 |
| Diff against target: |
567 lines (+411/-9) 4 files modified
include/location_service/com/ubuntu/location/provider.h (+43/-1) src/location_service/com/ubuntu/location/provider.cpp (+66/-8) tests/controller_test.cpp (+213/-0) tests/mock_delayed_provider.h (+89/-0) |
| To merge this branch: | bzr merge lp:~ssweeny/location-service/delayed-providers.15.04 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Thomas Voß (community) | 2015-10-22 | Approve on 2015-10-28 | |
|
Review via email:
|
|||
Commit Message
Add the concept of a delayed providers. This will allow providers that are slow to start the chance to be started and later be connected accordingly.
Description of the Change
Add the concept of a delayed providers. This will allow providers that are slow to start the chance to be started and later be connected accordingly.
- 199. By Scott Sweeny on 2015-10-27
-
Address review comments
- 200. By Scott Sweeny on 2015-10-27
-
Add logging output (move here from espoo-delayed-
providers MP) - 201. By Scott Sweeny on 2015-10-27
-
Add a log message that I missed
| Alberto Mardegan (mardy) wrote : | # |
I'm coming from a programming style that keeps virtual methods to a minimum, and I do understand if that might not be of your liking, so feel free to discard this comment. :-)
Wouldn't it be possible to implement the same without breaking the ABI?
At least, I see no reason why these methods need to be virtual:
virtual core::Signal<bool>& boot_state_
virtual const core::Signal<bool>& boot_state_
given that you are providing a default implementation that I don't see any reason to override. As for the getter:
virtual BootState boot_state() const;
this could be made non virtual by adding a protected method like
void set_boot_
that subclasses can call to set the boot state. This method would also take care of emitting the boot_state_
The only method for which a virtual declaration makes a lot of sense is request_boot(), but OTOH I wonder if we could remove it altogether: we could just specify that boot should start when the provider's constructor is invoked, or (if we really need a two-phase initialization) when the
virtual const Controller::Ptr& state_controller() const;
method is first invoked (it's a virtual method, so the subclass can use it to start the initialization). I can see that purists might not like to have this method be overloaded with the booting role too, but it's something that can make sense, if clearly explained in a doc comment.
It all depends on whether preserving ABI is a goal or not.
Unmerged revisions
- 201. By Scott Sweeny on 2015-10-27
-
Add a log message that I missed
- 200. By Scott Sweeny on 2015-10-27
-
Add logging output (move here from espoo-delayed-
providers MP) - 199. By Scott Sweeny on 2015-10-27
-
Address review comments
- 198. By Manuel de la Peña on 2015-10-22
-
Added support for delayed providers.


Please note that this change requires a rebuild of lp:espoo as the location::Provider interface is altered.