Skip to content
Snippets Groups Projects

Fix small issues

Merged Dylan Aïssi requested to merge wip/daissi/small-fixes into master
127 files
+ 157
157
Compare changes
  • Side-by-side
  • Inline
Files
127
@@ -22,12 +22,12 @@ one or more ***consumers*** receive information from one or more
## Use cases
- [Points of interest]( {{< ref "/points_of_interest.md" >}} ) should use one
- [Points of interest]( {{< ref "points_of_interest.md" >}} ) should use one
of these patterns
- [Sharing]( {{< ref "/sharing.md" >}} ) could use one of these patterns
- [Sharing]( {{< ref "sharing.md" >}} ) could use one of these patterns
- Global search (see [ConceptDesigns]( {{< ref "global-search.md" >}} ))
currently carries out the equivalent of
[interface discovery]( {{< ref "/interface_discovery.md" >}} ) by
[interface discovery]( {{< ref "interface_discovery.md" >}} ) by
reading the manifest directly, but other than that it is similar to
[Query-based access via D-Bus](#query-based-access-via-d-bus)
@@ -62,7 +62,7 @@ consumers and among providers.
## Discovery
Each initiator carries out [Interface
discovery]( {{< ref "/interface_discovery.md" >}} ) to find implementations of
discovery]( {{< ref "interface_discovery.md" >}} ) to find implementations of
the responder. If the initiator is the consumer, the interface that is
discovered might have a name like
`com.example.PointsOfInterestProvider`. If the initiator is the
@@ -374,7 +374,7 @@ If the system is restarted and the previously running applications are
restored, and the interface is one where resuming communication makes
sense, we recommend that the original initiator re-initiates
communication. This would normally be done by repeating [interface
discovery]( {{< ref "/interface_discovery.md" >}} ).
discovery]( {{< ref "interface_discovery.md" >}} ).
In a few situations it might be preferable for the original initiator to
store a list of the responders with which it was previously
Loading