Check-in [35b7b72ecd]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Clean up of dbusclient in preparation for 1.0 release.
Timelines: family | ancestors | descendants | both | dbusclient-develop
Files: files | file ages | folders
SHA1:35b7b72ecd0f7a5e03f919ad278cff4adc1b5175
User & Date: andrewm 2019-03-01 11:36:20
Context
2019-03-01
11:38
Removed extraneous test file for dbusclient. The thunder.test file is specific to having a particular board. check-in: af9ab33ec7 user: andrewm tags: dbusclient-develop
11:36
Clean up of dbusclient in preparation for 1.0 release. check-in: 35b7b72ecd user: andrewm tags: dbusclient-develop
2019-02-15
17:18
Checkpoint on dbusclient package development. check-in: 5ece104b90 user: andrewm tags: dbusclient-develop
Changes

Changes to dbusclient/src/Makefile.

1
2
3
4
5

6
7
8
9
10
11
12
...
144
145
146
147
148
149
150

151
152
153
154
155
156
157
158
159
160
161
162

163
164
165
166
167
168

169
170
171

172
173
174

175

176
177

178
179
180
181
182
183
184
185
186
187
#
#*++
# PROJECT:
#	Tools
# MODULE:

#
# ABSTRACT:
#
#*--
#

DOCDIR	= ../doc
................................................................................
code : $(CODEFILE)

module : $(MODULEFILE)

man : $(MANFILE)

$(MODULEFILE) : $(CODEFILE)

	cd $(CODEDIR) ; mkmodule $(PKGNAME) $(VERSION)\
		-script $(notdir $(CODEFILE))

runtests : $(TESTFILE) code $(TESTDIR)/test-server.tcl
	cd $(TESTDIR) ; tclsh $(notdir $(TESTFILE)) $(TESTOPTS)

clean :
	$(RM) $(CLEANFILES)

$(DOCSRC) : $(DOCPARTS)

$(DOCFILE) : $(DOCSRC) $(DOCPARTS) $(EXTRAS) $(IMAGES)

	a2x $(A2XOPTS) --doctype=article  --format=pdf\
	    --destination-dir=$(DOCDIR)\
	    $(ASCIIDOC_OPTS) $(DBLATEX_OPTS) $<
	$(RM) $(DOCDIR)/*__[0-9].pdf

$(CODEFILE) : $(DOCSRC) $(DOCPARTS)

	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)

$(TESTFILE) : $(DOCSRC) $(DOCPARTS)

	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)

$(TESTDIR)/test-server.tcl : $(DOCSRC) $(DOCPARTS)

	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)


$(MANFILE) : $(DOCSRC) $(DOCPARTS)

	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)

$(IMAGEDIR)/%.pdf : %.uxf
	umlet -action=convert -format=pdf\
		-filename=$< -output=$(basename $@)


#
# vim: sw=8 ts=8 sts=8 noexpandtab
#



|

>







 







>












>






>



>



>

>


>










1
2
3
4
5
6
7
8
9
10
11
12
13
...
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
#
#*++
# PROJECT:
#	dbusclient
# MODULE:
#	Make file for dbusclient package
#
# ABSTRACT:
#
#*--
#

DOCDIR	= ../doc
................................................................................
code : $(CODEFILE)

module : $(MODULEFILE)

man : $(MANFILE)

$(MODULEFILE) : $(CODEFILE)
	@mkdir -p $(CODEDIR)
	cd $(CODEDIR) ; mkmodule $(PKGNAME) $(VERSION)\
		-script $(notdir $(CODEFILE))

runtests : $(TESTFILE) code $(TESTDIR)/test-server.tcl
	cd $(TESTDIR) ; tclsh $(notdir $(TESTFILE)) $(TESTOPTS)

clean :
	$(RM) $(CLEANFILES)

$(DOCSRC) : $(DOCPARTS)

$(DOCFILE) : $(DOCSRC) $(DOCPARTS) $(EXTRAS) $(IMAGES)
	@mkdir -p $(DOCDIR)
	a2x $(A2XOPTS) --doctype=article  --format=pdf\
	    --destination-dir=$(DOCDIR)\
	    $(ASCIIDOC_OPTS) $(DBLATEX_OPTS) $<
	$(RM) $(DOCDIR)/*__[0-9].pdf

$(CODEFILE) : $(DOCSRC) $(DOCPARTS)
	@mkdir -p $(CODEDIR)
	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)

$(TESTFILE) : $(DOCSRC) $(DOCPARTS)
	@mkdir -p $(TESTDIR)
	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)

$(TESTDIR)/test-server.tcl : $(DOCSRC) $(DOCPARTS)
	@mkdir -p $(TESTDIR)
	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)
	chmod +x $@

$(MANFILE) : $(DOCSRC) $(DOCPARTS)
	@mkdir -p $(MANDIR)
	atangle $(ATANGLEOPTS) -root $(notdir $@) -output $@ $(DOCSRC)

$(IMAGEDIR)/%.pdf : %.uxf
	umlet -action=convert -format=pdf\
		-filename=$< -output=$(basename $@)


#
# vim: sw=8 ts=8 sts=8 noexpandtab
#

Changes to dbusclient/src/codeorg.txt.

1
2




3
4



5
6
7
8
9
10
11
..
23
24
25
26
27
28
29

30
31
32
33
34
35

36
37
38
39
40
41
42
..
60
61
62
63
64
65
66


67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
..
93
94
95
96
97
98
99












100
101
102
103
104
105
106
...
141
142
143
144
145
146
147










148
149
150
151
152
153
154
155
== Code Organization





=== Package source code




[source,tcl]
----
<<dbusclient.tcl>>=
<<edit warning>>
<<copyright info>>

<<required packages>>
................................................................................
package provide dbusclient 1.0
----

=== Unit tests

Part of the literate program documentation is to show the test cases
for the code.

In the document,
we have included the test cases near to the code they test.
In this section,
the root chunk for the tests is defined.

The package uses `tcltest` to run and tally the tests.


(((chunk,dbusclient.test)))
[source,tcl]
----
<<dbusclient.test>>=
<<edit warning>>
<<copyright info>>
................................................................................
    log::info "testing dbusclient version: [package require dbusclient]"

    namespace import ::tcltest::*
    namespace import ::dbusclient::*

    <<test utilities>>



    <<connection tests>>
    <<service tests>>

    killServer

    cleanupTests
}
----

We collect all the additional packages required for the tests into
one place.

(((chunk,required packages)))
[source,c]
----
<<required packages for test>>=
<<required packages>>
package require tcltest
package require cmdline
----
................................................................................
} -cleanup {
} -body {
} -result {}
----
////

=== Reference documentation













(((chunk,dbusclient.man)))
[source,tcl]
----
<<dbusclient.man>>=
[comment {
<<edit warning>>
................................................................................

[subsection "Service object methods"]
The following methods are available for [class Service] objects.

[list_begin definitions]
<<man service methods>>
[list_end]











[keywords DBus]

[manpage_end]
----

// vim:set syntax=asciidoc:



>
>
>
>


>
>
>







 







>


<
|
<
<
>







 







>
>



|








|







 







>
>
>
>
>
>
>
>
>
>
>
>







 







>
>
>
>
>
>
>
>
>
>








1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
..
30
31
32
33
34
35
36
37
38
39

40


41
42
43
44
45
46
47
48
..
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
...
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
...
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
== Code Organization

In this section,
we show how the literate program chunks defined previously
are composed into the various source code files.

=== Package source code

The package source code is delivered in a file named, _dbusclient.tcl_.
The following chunk is a root chunk for extracting the package source code.

[source,tcl]
----
<<dbusclient.tcl>>=
<<edit warning>>
<<copyright info>>

<<required packages>>
................................................................................
package provide dbusclient 1.0
----

=== Unit tests

Part of the literate program documentation is to show the test cases
for the code.
The package uses `tcltest` to run and tally the tests.
In the document,
we have included the test cases near to the code they test.

The package tests are delivered in a file name, _dbusclient.test_.


The following chunk is a root chunk for extracting the package unit tests.

(((chunk,dbusclient.test)))
[source,tcl]
----
<<dbusclient.test>>=
<<edit warning>>
<<copyright info>>
................................................................................
    log::info "testing dbusclient version: [package require dbusclient]"

    namespace import ::tcltest::*
    namespace import ::dbusclient::*

    <<test utilities>>

    <<test server setup>>

    <<connection tests>>
    <<service tests>>

    <<test server cleanup>>

    cleanupTests
}
----

We collect all the additional packages required for the tests into
one place.

(((chunk,required packages for test)))
[source,c]
----
<<required packages for test>>=
<<required packages>>
package require tcltest
package require cmdline
----
................................................................................
} -cleanup {
} -body {
} -result {}
----
////

=== Reference documentation

The manpage or reference documentation has been included in the
literate program source as comments.
This allows the documentation to be near the code it describes,
but by placing it in a comment, it does not clutter the text itself.

The manpages are formated with Tcl doctools that can be found in
`tcllib` and can be transformed into HTML (among other forms) using
`dtplite`.
The document is place in a file named, _dbuclient.man_.
The following chunk is a root chunk for extracting the package manpage
document.

(((chunk,dbusclient.man)))
[source,tcl]
----
<<dbusclient.man>>=
[comment {
<<edit warning>>
................................................................................

[subsection "Service object methods"]
The following methods are available for [class Service] objects.

[list_begin definitions]
<<man service methods>>
[list_end]

[section Dependencies]

The [package dbusclient] package depends upon three binary Tcl packages.

[list_begin itemized]
[item] [package dbus] is the Tcl bindings to the DBus library.
[item] [package tcom] is used to parse XML returned during introspection.
[item] [package ral] is used to manage the introspection data.
[list_end]

[keywords DBus]

[manpage_end]
----

// vim:set syntax=asciidoc:

Changes to dbusclient/src/dbusclient-docinfo.xml.

10
11
12
13
14
15
16








17
    <revnumber>0.1</revnumber>
    <date>January 23, 2019</date>
    <authorinitials>GAM</authorinitials>
    <revremark>
      Initial coding.
    </revremark>
  </revision>








</revhistory>







>
>
>
>
>
>
>
>

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
    <revnumber>0.1</revnumber>
    <date>January 23, 2019</date>
    <authorinitials>GAM</authorinitials>
    <revremark>
      Initial coding.
    </revremark>
  </revision>
  <revision>
    <revnumber>1.0</revnumber>
    <date>March 1, 2019</date>
    <authorinitials>GAM</authorinitials>
    <revremark>
      Initial release.
    </revremark>
  </revision>
</revhistory>

Changes to dbusclient/src/docinfo.xml.

1
2
3
4
5
6
7
8
9
10
11
12
13
<!--
     This file is used with asciidoc to provide additional text for the
     docbook XML output. Fill out the <subtitle> and <author> tags.
-->
<subtitle>
    A Tcl package for DBus Interactions
</subtitle>
<authorgroup>
  <author>
    <firstname>Andrew</firstname>
    <surname>Mangogna</surname>
  </author>
</authorgroup>





|







1
2
3
4
5
6
7
8
9
10
11
12
13
<!--
     This file is used with asciidoc to provide additional text for the
     docbook XML output. Fill out the <subtitle> and <author> tags.
-->
<subtitle>
    A Tcl package for DBus Client Interactions
</subtitle>
<authorgroup>
  <author>
    <firstname>Andrew</firstname>
    <surname>Mangogna</surname>
  </author>
</authorgroup>

Changes to dbusclient/src/edit-warning.txt.

1
2
3
4
5

6
7
8
9
10
11
12
13
14

=== Edit Warning

We want to make sure to warn readers that the source code is generated and
not manually written.


(((chunk,edit warning)))
----
<<edit warning>>=
#
# DO NOT EDIT THIS FILE!
# THIS FILE IS AUTOMATICALLY GENERATED FROM A LITERATE PROGRAM SOURCE FILE.
#
----



|
|
>






|


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

=== Edit Warning

We want to make sure to warn readers that the source code is extracted
and editing the extracted file breaks the correspondence with the
ultimate source, the literate program source.

(((chunk,edit warning)))
----
<<edit warning>>=
#
# DO NOT EDIT THIS FILE!
# THIS FILE IS AUTOMATICALLY EXTRACTED FROM A LITERATE PROGRAM SOURCE FILE.
#
----

Changes to dbusclient/src/figures/service-metadata.uxf.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
..
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
..
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
..
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
...
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
...
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
...
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
...
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.3.0">
  <zoom_level>10</zoom_level>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>20</x>
      <y>240</y>
      <w>120</w>
      <h>50</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Path
-
Name : string {I}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>390</x>
      <y>240</y>
      <w>120</w>
      <h>50</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Interface
-
Name : string {I}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>130</x>
      <y>240</y>
      <w>280</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R1
m1=0..*
r1=describes the\nfunctions of
................................................................................
r2=functions\naccording to
</panel_attributes>
    <additional_attributes>10.0;30.0;260.0;30.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>200</x>
      <y>430</y>
      <w>160</w>
      <h>70</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Implemention
-
................................................................................
Path : string {I,R1}
Interface : string {I,R1}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>260</x>
      <y>260</y>
      <w>30</w>
      <h>190</h>
    </coordinates>
    <panel_attributes>lt=.</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;170.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>810</x>
      <y>240</y>
      <w>160</w>
      <h>70</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Member
-
................................................................................
Interface : string {I,R2}
Name : string {I}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>500</x>
      <y>240</y>
      <w>330</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R2
m1=1
r1=is an\nelement of
................................................................................
r2=encapsulates\nfunctionality as
</panel_attributes>
    <additional_attributes>10.0;30.0;310.0;30.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>620</x>
      <y>430</y>
      <w>160</w>
      <h>100</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Property
-
Interface : string {I,R3}
Name : string {I}
Type : string
Access : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>810</x>
      <y>430</y>
      <w>160</w>
      <h>80</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Method
-
Interface : string {I,R3}
Name : string {I}
Signature : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>1010</x>
      <y>430</y>
      <w>160</w>
      <h>80</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Signal
-
Interface : string {I,R3}
Name : string {I}
Signature : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>690</x>
      <y>360</y>
      <w>410</w>
      <h>90</h>
    </coordinates>
    <panel_attributes>lt=-
</panel_attributes>
    <additional_attributes>10.0;70.0;10.0;20.0;390.0;20.0;390.0;70.0</additional_attributes>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>870</x>
      <y>300</y>
      <w>40</w>
      <h>150</h>
    </coordinates>
    <panel_attributes>lt=&lt;&lt;-
R3</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;130.0</additional_attributes>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>350</x>
      <y>440</y>
      <w>290</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R5
m1=0..*
r1=describes a\ndata type of
................................................................................
r2=is characterized\nby
</panel_attributes>
    <additional_attributes>10.0;30.0;270.0;30.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>400</x>
      <y>570</y>
      <w>160</w>
      <h>110</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
PropertyValue
-
Path : string {I,R4}
Interface : string {I,R4}
Property : string {I}
Value : string
Valid : boolean</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>470</x>
      <y>460</y>
      <w>30</w>
      <h>130</h>
    </coordinates>
    <panel_attributes>lt=.</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;110.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>820</x>
      <y>660</y>
      <w>160</w>
      <h>100</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Argument
-
Interface : string {I,R5}
Method : string {I,R5}
Name : string {I}
Type : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>880</x>
      <y>500</y>
      <w>170</w>
      <h>180</h>
    </coordinates>
    <panel_attributes>lt=-
R4
m1=1
r1=describes a\nparameter of
................................................................................
r2=is provided parameters\ndescribed by
</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;160.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>1180</x>
      <y>240</y>
      <w>160</w>
      <h>100</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Annotation
-
................................................................................
Name : string {I}
Value : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>960</x>
      <y>240</y>
      <w>240</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R6
m1=1
r1=applies to
m2=0..*
r2=is described\nby</panel_attributes>
    <additional_attributes>10.0;30.0;220.0;30.0</additional_attributes>
  </element>
</diagram>






|
|













|
|













|
|







 







|
|







 







|
|









|
|







 







|
|







 







|
|








|







|
|








|






|
|








|






|
|










|
|










|
|







 







|
|







|
|








|
|









|
|







|
|







|
|







 







|
|







 







|
|












1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
..
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
..
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
..
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
...
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
...
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
...
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
...
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.3.0">
  <zoom_level>10</zoom_level>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>0</x>
      <y>220</y>
      <w>120</w>
      <h>50</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Path
-
Name : string {I}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>370</x>
      <y>220</y>
      <w>120</w>
      <h>50</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Interface
-
Name : string {I}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>110</x>
      <y>220</y>
      <w>280</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R1
m1=0..*
r1=describes the\nfunctions of
................................................................................
r2=functions\naccording to
</panel_attributes>
    <additional_attributes>10.0;30.0;260.0;30.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>180</x>
      <y>410</y>
      <w>160</w>
      <h>70</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Implemention
-
................................................................................
Path : string {I,R1}
Interface : string {I,R1}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>240</x>
      <y>240</y>
      <w>30</w>
      <h>190</h>
    </coordinates>
    <panel_attributes>lt=.</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;170.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>790</x>
      <y>220</y>
      <w>160</w>
      <h>70</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Member
-
................................................................................
Interface : string {I,R2}
Name : string {I}</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>480</x>
      <y>220</y>
      <w>330</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R2
m1=1
r1=is an\nelement of
................................................................................
r2=encapsulates\nfunctionality as
</panel_attributes>
    <additional_attributes>10.0;30.0;310.0;30.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>600</x>
      <y>410</y>
      <w>160</w>
      <h>100</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Property
-
Interface : string {I,R3}
Name : string {I,R3}
Type : string
Access : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>790</x>
      <y>410</y>
      <w>160</w>
      <h>80</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Method
-
Interface : string {I,R3}
Name : string {I,R3}
Signature : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>990</x>
      <y>410</y>
      <w>160</w>
      <h>80</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Signal
-
Interface : string {I,R3}
Name : string {I,R3}
Signature : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>670</x>
      <y>340</y>
      <w>410</w>
      <h>90</h>
    </coordinates>
    <panel_attributes>lt=-
</panel_attributes>
    <additional_attributes>10.0;70.0;10.0;20.0;390.0;20.0;390.0;70.0</additional_attributes>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>850</x>
      <y>280</y>
      <w>40</w>
      <h>150</h>
    </coordinates>
    <panel_attributes>lt=&lt;&lt;-
R3</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;130.0</additional_attributes>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>330</x>
      <y>420</y>
      <w>290</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R5
m1=0..*
r1=describes a\ndata type of
................................................................................
r2=is characterized\nby
</panel_attributes>
    <additional_attributes>10.0;30.0;270.0;30.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>380</x>
      <y>550</y>
      <w>160</w>
      <h>110</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
PropertyValue
-
Path : string {I,R5}
Interface : string {I,R5}
Property : string {I}
Value : string
Valid : boolean</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>450</x>
      <y>440</y>
      <w>30</w>
      <h>130</h>
    </coordinates>
    <panel_attributes>lt=.</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;110.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>800</x>
      <y>640</y>
      <w>160</w>
      <h>100</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Argument
-
Interface : string {I,R4}
Method : string {I,R4}
Name : string {I}
Type : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>860</x>
      <y>480</y>
      <w>170</w>
      <h>180</h>
    </coordinates>
    <panel_attributes>lt=-
R4
m1=1
r1=describes a\nparameter of
................................................................................
r2=is provided parameters\ndescribed by
</panel_attributes>
    <additional_attributes>10.0;10.0;10.0;160.0</additional_attributes>
  </element>
  <element>
    <id>UMLClass</id>
    <coordinates>
      <x>1160</x>
      <y>220</y>
      <w>160</w>
      <h>100</h>
    </coordinates>
    <panel_attributes>style=autoresize
bg=yellow
Annotation
-
................................................................................
Name : string {I}
Value : string</panel_attributes>
    <additional_attributes/>
  </element>
  <element>
    <id>Relation</id>
    <coordinates>
      <x>940</x>
      <y>220</y>
      <w>240</w>
      <h>60</h>
    </coordinates>
    <panel_attributes>lt=-
R6
m1=1
r1=applies to
m2=0..*
r2=is described\nby</panel_attributes>
    <additional_attributes>10.0;30.0;220.0;30.0</additional_attributes>
  </element>
</diagram>

Changes to dbusclient/src/introduction.txt.

2
3
4
5
6
7
8








9
10
11
12
13


== Introduction

This document is about a Tcl package named `dbusclient`.
`Dbusclient` is a Tcl package that facilitates interacting with
a DBus daemon to obtain services from other programs on a DBus.









This document is also a
http://www.literateprogramming.com/[literate program]
and contains all the design information and code for the `posixipc` package.
Readers unfamiliar with literate programs should consult the
<<literate-programming,section below>> for more details.








>
>
>
>
>
>
>
>


|

|
>
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

== Introduction

This document is about a Tcl package named `dbusclient`.
`Dbusclient` is a Tcl package that facilitates interacting with
a DBus daemon to obtain services from other programs on a DBus.

DBus is an inter-process communications mechanism that supports
remote procedure call and asynchronous notifications.
It is typically used in Linux systems to provide a means for
various system services to be organized.
The
https://dbus.freedesktop.org/doc/dbus-specification.html[DBus specification]
gives the details of the protocol.

This document is also a
http://www.literateprogramming.com/[literate program]
and contains all the design information and code for the `dbusclient` package.
Readers unfamiliar with literate programs should consult the
<<literate-programming,section below>> for more details
on the syntax of literate programming chunks used in this document.

Changes to dbusclient/src/litprog.txt.

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
..
47
48
49
50
51
52
53
54
55
56
57
58
59
60



61
62
63
64
65
66
67
68
The source for this document conforms to
http://www.methods.co.nz/asciidoc/[asciidoc] syntax.
This document is also a
http://www.literateprogramming.com/[literate program].
The source code for the implementation is included directly in the document
source and the build process extracts the source that is then given to the Tcl
interpreter.
This process is known as __tangle__ing.
The program,
http://repos.modelrealization.com/cgi-bin/fossil/tcl-cm3/[+atangle+],
is available to extract source code from the document source
and the +asciidoc+ tool chain can be used to produce a variety
of different output formats, although PDF is the intended choice.

The goal of a literate program is to explain the logic of the
................................................................................
Multiple definitions with the same name are simply concatenated in the order
they are encountered.
There are one or more _root chunks_ which form the conceptual tree
for the source files that are contained in the literate source.
By convention, root chunks are named the same as the file name to
which they will be tangled.
Tangling is then the operation of starting at a root chunk and
recursively substituting the definition for the chunk references that
are encountered.

For readers that are not familiar with the literate style and
who are adept at reading source code directly,
the chunks definitions and reordering
provided by the tangle operation can be a bit disconcerting at first.



You can, of course, examine the tangled source output,
but if you read the literate program as a document,
you will have to trust that the
author managed to arrange the chunk definitions and references in
a manner so that the tangled output is acceptable to a language
compiler or interpreter.

// vim:set syntax=asciidoc:







|







 







|






>
>
>








8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
..
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
The source for this document conforms to
http://www.methods.co.nz/asciidoc/[asciidoc] syntax.
This document is also a
http://www.literateprogramming.com/[literate program].
The source code for the implementation is included directly in the document
source and the build process extracts the source that is then given to the Tcl
interpreter.
This extraction process is known as __tangle__ing.
The program,
http://repos.modelrealization.com/cgi-bin/fossil/tcl-cm3/[+atangle+],
is available to extract source code from the document source
and the +asciidoc+ tool chain can be used to produce a variety
of different output formats, although PDF is the intended choice.

The goal of a literate program is to explain the logic of the
................................................................................
Multiple definitions with the same name are simply concatenated in the order
they are encountered.
There are one or more _root chunks_ which form the conceptual tree
for the source files that are contained in the literate source.
By convention, root chunks are named the same as the file name to
which they will be tangled.
Tangling is then the operation of starting at a root chunk and
recursively substituting the definitions of the chunk references that
are encountered.

For readers that are not familiar with the literate style and
who are adept at reading source code directly,
the chunks definitions and reordering
provided by the tangle operation can be a bit disconcerting at first.
However,
there is much more information in the literate program document than
in the tangled source.
You can, of course, examine the tangled source output,
but if you read the literate program as a document,
you will have to trust that the
author managed to arrange the chunk definitions and references in
a manner so that the tangled output is acceptable to a language
compiler or interpreter.

// vim:set syntax=asciidoc:

Changes to dbusclient/src/package.txt.

1











2
3
4
5
6
7
8
..
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

42
43
44
45
46
47
48
49
50
51
52
53
54
55

56
57
58
59
60
61
62
...
136
137
138
139
140
141
142

143
144
145

146

147
148
149
150
151
152
153
...
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
...
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
...
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
...
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
....
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
....
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487

1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500




1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513





1514
1515
1516
1517
1518


1519
1520
1521
1522
1523
1524
1525
....
1528
1529
1530
1531
1532
1533
1534


1535
1536
1537
1538
1539
1540
1541
1542
1543


1544
1545
1546

1547
1548
1549



1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562






1563



1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
....
1616
1617
1618
1619
1620
1621
1622





1623
1624
1625
1626
1627
1628
1629
....
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
....
2000
2001
2002
2003
2004
2005
2006



2007
2008
2009
2010
2011
2012
2013
....
2023
2024
2025
2026
2027
2028
2029



2030
2031
2032
2033
2034
2035
2036
....
2054
2055
2056
2057
2058
2059
2060



2061
2062
2063
2064
2065
2066
2067
....
2142
2143
2144
2145
2146
2147
2148



2149
2150
2151
2152
2153
2154
2155
....
2174
2175
2176
2177
2178
2179
2180




2181
2182
2183
2184
2185
2186
2187
....
2324
2325
2326
2327
2328
2329
2330
2331


















2332
2333
2334
2335
2336
2337
2338
....
2404
2405
2406
2407
2408
2409
2410



2411
2412
2413
2414
2415
2416
2417
....
2419
2420
2421
2422
2423
2424
2425



2426
2427
2428
2429
2430
2431
2432
2433




































2434
2435
2436
2437
2438
2439
2440
....
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
....
2563
2564
2565
2566
2567
2568
2569



2570
2571
2572
2573
2574
2575
2576
....
2649
2650
2651
2652
2653
2654
2655






2656
2657
2658
2659
2660
2661
2662
....
2663
2664
2665
2666
2667
2668
2669





2670
2671
2672
2673
2674
2675
2676
....
2719
2720
2721
2722
2723
2724
2725




2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
....
2817
2818
2819
2820
2821
2822
2823



2824
2825
2826
2827
2828
2829
2830
....
2840
2841
2842
2843
2844
2845
2846




2847
2848
2849
2850
2851
2852
2853
== Package Overview












The `dbusclient` package builds upon the Tcl bindings to DBus
contained in the
http://chiselapp.com/user/schelte/repository/dbus[`dbus`]
package by Schelte Bron.
The `dbus` package provides the fundamental interface to the
DBus ``C'' library used to access the DBus daemon.
................................................................................

[source,tcl]
----
<<required packages>>=
package require dbus
----

The `dbusclient` package is implemented as two classes using TclOO.
This means we need a relatively new version of Tcl.
Since we also tend to use the latest Tcl commands,
we'll insist upon the latest Tcl version (as of this writing).

[source,tcl]
----
<<required packages>>=
package require Tcl 8.6
----

///////
----
<<man description>>=
[description]
This manpage describes the
[package dbusclient]
package which is a Tcl script extension that simplifies
client side programing for access to services on the DBus.
----
///////

The two TclOO class commands are exported from the namespace and a
namespace ensemble is created with them.

[source,tcl]
----
<<package exports>>=
namespace export Connection
namespace export Service
----

/////////
----
<<man commands section>>=

[section Commands]
The two TclOO class commands are exported from the [package dbusclient]
namespace and the form a namespace ensemble.

----
/////////

=== Connection class

The `Connection` class represents the communications connection to a
DBus daemon.
................................................................................
we want to make sure to destroy any services that may be using this connection.
So we have to iterate across any connected services.

[source,tcl]
----
<<connection methods>>=
destructor {

    foreach service [my FindConnectedServices] {
        $service destroy
    }

    ::dbus close $busId

}
----

/////////
----
<<man connection methods>>=
[call [cmd "[arg connobj] destroy"]]
................................................................................
a method is a member of an interface that is supported by an object
instance.
Calling the method is a request to perform the function of the method.

The only complication here deals with the signature of the method.
The `dbus` package documentation describes the details of signatures in DBus,
but, as you might suspect, it is a means of dealing with DBus data typing
in the face of Tcl insisting that_everything is a string_.
We interpret an empty string signature as not wishing to pass in the
signature to the `dbus` command.
Later we will see that internally,
[cmd Service] objects always supply the signature because it is
available from the service introspection.

[source,tcl]
----
<<connection methods>>=
method call {target path interface method sig args} {
    set cmd [list ::dbus call $busId -dest $target]
................................................................................
<<man connection methods>>=
[call [cmd "[arg connobj] filter"] [arg subcmd] [arg [opt "arg1 arg2 ..."]]]
----
/////////

=== Service class

The `Service` class represents the name of a service provider on a
DBus.
Server programs may connect to the DBus daemon and request a name for the
connection.
This name typically follows an inverted URI host name (_e.g._ com.example).
In DBus terms,
these are bus names and give the target to which service requests may be
directed.
You can think of bus names as being similar to _well known_ ports in
................................................................................
To know what objects and interfaces are supported by a service,
the objects of the service support the standard interface,
`org.freedesktop.DBus.Introspectable`.

By using the `Introspect` method in this interface it is possible to uncover
all the objects and interfaces supported by a service.
The `dbusclient` package caches this information to make various
tasks easier, such immediate access to property values and keeping
track of property values when they change.
In this section,
we show a class diagram of the how the service metadata is held.

.Class Diagram for DBus Service Metadata
image::service-metadata.pdf[]

................................................................................
Better than just sandwiching a "/" between the path and its child node
name using sting concatenation.
<2> Here is the recursive introspection to obtain the information for
child nodes.

Once we know all the paths and interfaces in a service and know
which interfaces are implemented by which paths,
then we can *PropertyValue* tuples for the properties that are associated with
a given path.
At this point,
we don't know the values of the properties,
so each property value is set to the empty string and marked as invalid.

[source,tcl]
----
<<service methods>>=
................................................................................
        relation restrictwith ~ {$Path eq $path} |
        relation list ~ Interface
    }]
}
----

For these tests, we want to be able to compare sets for equality.
Fortunately, `tcllib` provides all the need commands and
`tcltest` allows us to define custom matching procedures.

.Tests

[source,tcl]
----
<<required packages for test>>=
................................................................................

==== A test server

It is convenient to put up our own service against which we can test.
Fortunately,
the [package dbif] package, also by Schelte Bron, provides some
convenient commands to do that.
In this section we show a test server build using
the [package dbif] package.
This server is then used for testing other parts of this package.

[source,tcl]
----
<<test-server.tcl>>=

package require dbif

puts stderr "test server starting"

dbif connect -bus session -noqueue -replace com.modelrealization.test

<<test server methods>>
<<test server properties>>
<<test server signals>>

vwait forever
----





[source,tcl]
----
<<test server methods>>=
dbif method /com/modelrealization/test AddToCounter {cnt} {i} {
    incr ::Counter $cnt
    dbif return $msgid $::Counter
}

dbif method /com/modelrealization/test Quit {
    dbif return $msgid {}
    puts stderr "test server exiting"
    exit
}






dbif method /com/modelrealization/test Trigger {
    dbif generate $::AttnSigId
}
----



[source,tcl]
----
<<test server properties>>=
dbif property -attributes {Property.EmitsChangedSignal true}\
        /com/modelrealization/test Counter:i Counter
set ::Counter 0
................................................................................
set ::Name "Test Server"

dbif property -access read\
        /com/modelrealization/test Source:s Source
set ::Source "Model Realization"
----



[source,tcl]
----
<<test server signals>>=
set ::AttnSigId [dbif signal /com/modelrealization/test Attention\
        {Count:i Identity:s} {} {
    return [list $::Counter $::Source]
}]
----



[source,tcl]
----
<<test utilities>>=

exec tclsh test-server.tcl &
----




[source,tcl]
----
<<test utilities>>=
proc killServer {} {
    set conn [Connection create sessionBus session]
    Service create tserver com.modelrealization.test $conn
    tserver call /com/modelrealization/test com.modelrealization.test\
            Quit

    $conn destroy
}
----







==== Calling methods




[source,tcl]
----
<<service methods>>=
method call {path interface method args} {
    my ValidateCall $path $interface $method $args
    my variable svcName
    my variable connId
    tailcall $connId call $svcName $path $interface $method\
        [my methodSignature $interface $method] {*}$args
}
----

.Tests

................................................................................
in [arg interface] on the the object specified by [arg path].
Additional optional [arg argN] arguments are passes as arguments to
the called method.
The return value of the [method call] method is the return value of
the underlying service method from the DBus.
----
/////////






[source,tcl]
----
<<service methods>>=
method ValidateCall {path interface method arglist} {
    my ValidatePath $path
    my ValidateInterface $path $interface
................................................................................
/////////

==== Tracing properties and signals

Services on the DBus usually implement asynchronous notifications when
a property value is changed or when new paths and interfaces are
added or removed.
The [package dbusclient] package handles these asynchronous notifications and
updates the values in the service metadata if the Tcl event loop is entered.
The package also provides an interface to allow programs using
[package dbusclient] to be informed of the changes.
This is accomplished by [emph tracing] the various aspects
of the DBus service.

The tracing supported by [package dbusclient] has an interface modeled
after the Tcl core [cmd trace] command.
For the DBus,
we can trace on properties, signals or paths.

The following is a class diagram of the metadata that is held
to support tracing of DBus entities.

.Class Diagram for Tracing Metadata
image::trace-metadata.pdf[]

The diagram shows that there are three types of traces (R3).
Each trace has an identifier, a path matching pattern and a command prefix.
The path matching pattern is specified as in the [cmd "string match"] command
and qualifies traces to the path names they must match.
The command prefix is executed when the DBus send an asynchronous notification
and the conditions of the trace are matched.
Property traces are further qualified by the interface and property name
that is traced.
Similarly, signal traces are qualified by teh interface and signal name
they must match.
In both cases,
property traces and signal traces must be related to a property or
signal defined by an interface (R8 and R9).

Following the pattern we used for service metadata,
the previous diagram can be rendered as TclRAL `relvar` commands
to establish the trace metadata schema.

[source,tcl]
----
................................................................................
        Signal {Interface Name} 1

relvar association R9\
        PropertyTrace {Interface Property} *\
        Property {Interface Name} 1
----




[source,tcl]
----
<<service methods>>=
method trace {operation args} {
    switch -exact $operation {
        add {
            set result [my AddTrace $args]
................................................................................
                expected add, remove or info"
            throw [list TRACE UNKNOWNOP $msg] $msg
        }
    }
    return $result
}
----




[source,tcl]
----
<<service methods>>=
method AddTrace {argList} {
    if {[llength $argList] < 2} {
        set msg "wrong # of args, expected: trace add tracetype args"
................................................................................
            throw [list TRACE UNKNOWNTYPE $msg] $msg
        }
    }

    return $traceid
}
----




[source,tcl]
----
<<service methods>>=
method AddPathTrace {argList} {
    if {[llength $argList] != 2} {
        set msg "wrong # of args, expected: trace add path\
................................................................................
        ]
    }

    return $traceNumber
}
----




[source,tcl]
----
<<service methods>>=
method RmTrace {traceid} {
    set trace [pipe {
        relvar restrictone Trace TraceId $traceid |
        rvajoin ~ [relvar set PathTrace] Path |
................................................................................
        }
    }
    return
}
----
<1> Remove any bus message listening associated with the signal.





[source,tcl]
----
<<service methods>>=
method InfoTrace {traceid} {
    set trace [pipe {
        relvar restrictone Trace TraceId $traceid |
        rvajoin ~ [relvar set PathTrace] Path |
................................................................................

For [var path] type traces no additional information is provided.

[list_end]
----
/////////

==== Synchronizing to traces



















[source,tcl]
----
<<service methods>>=
method waitForProperty {interface property pathpattern trigger {timeout 5000}} {
    set timerid {}
    if {$timeout != 0} {
................................................................................
[def value]
The new value of the property if the status element has a value of
[cmd changed].
[list_end]
----
/////////




[source,tcl]
----
<<service methods>>=
method PropertySync {status path interface property value} {
    set [my varname propSync] [dict create\
        status $status\
        path $path\
................................................................................
        property $property\
        value $value\
    ]
    return
}
----




[source,tcl]
----
<<service methods>>=
method PropertySyncTimeout {} {
    set [my varname propSync] TIMEOUT
    return
}
----





































/////////
----
<<man service methods>>=
[call [cmd "[arg svcobj] waitForSignal"] [arg interface] [arg signal]\
    [arg pathpattern] [arg trigger] [arg [opt timeout]]]

................................................................................
The argument signature of the signal.
[def args]
A list of argument values that came with the signal.
[list_end]
----
/////////

[source,tcl]
----
<<service methods>>=
method waitForSignal {interface signal pathpattern trigger {timeout 5000}} {
    set timerid {}
    if {$timeout != 0} {
        set timerid [::after $timeout [mymethod SignalSyncTimeout]]
    }
    set traceId [my trace add signal $interface $signal $pathpattern\
            [mymethod SignalSync]]
    try {
        set result [uplevel 1 $trigger]

        vwait [my varname sigSync]
        if {$timerid ne {}} {
            ::after cancel $timerid
        }
    } on error {result opts} {
        return -options $opts $result
    } finally {
        my trace remove $traceId
    }

    variable sigSync
    if {$sigSync eq "TIMEOUT"} {
        set msg "timed out waiting for signal change: $interface $signal\
                $pathpattern $trigger"
        throw [list SIGNAL TIMEOUT $msg] $msg
    }
    return $sigSync
}
----

[source,tcl]
----
<<service tests>>=
test signal-1.0 {
    Wait for a signal
} -setup {
    set conn [Connection create sessionBus session]
................................................................................
<<service methods>>=
method SignalSyncTimeout {} {
    set [my varname sigSync] TIMEOUT
    return
}
----




[source,tcl]
----
<<service methods>>=
method waitForPath {pathpattern trigger {timeout 5000}} {
    set timerid {}
    if {$timeout != 0} {
        set timerid [::after $timeout [mymethod PathSyncTimeout]]
................................................................................
    set [my varname pathSync] TIMEOUT
    return
}
----

==== Callbacks for signals







[source,tcl]
----
<<service methods>>=
method HandleSignals {eventInfo args} {
    log::debug [info level 0]
    set interface [dict get $eventInfo interface]
    set signal [dict get $eventInfo member]
................................................................................
    set path [dict get $eventInfo path]

    my EvalTrace signal {$Interface eq $interface &&\
            $Signal eq $signal &&\
            [string match $PathMatch $path]} $eventInfo {*}$args
}
----






[source,tcl]
----
<<service methods>>=
method EvalTrace {tracetype predicate args} {
    set typeMap [dict create\
        path PathTrace\
................................................................................
[source,tcl]
----
<<service methods>>=
method TracePath {status path} {
    my EvalTrace path {[string match $PathMatch $path]} $status $path
}
----





[source,tcl]
----
<<service methods>>=
# signature oa{sa{sv}}
method InterfacesAdded {eventInfo path interfaces} {
    relvar eval {
        dict for {interface properties} $interfaces {
            set added [my AddNewInterface $interface $path]
            if {!$added} {
                # At this point we failed to find the interface
                # in the introspection XML. The best we can do
................................................................................
    if {[relation isempty $pathRel]} {
        relvar insert Path [list Name $path]
        my TracePath added $path
    }
}
----




[source,tcl]
----
<<service methods>>=
method InterfacesRemoved {eventInfo path interfaces} {
    relvar eval {
        foreach interface $interfaces {
            relvar deleteone Implementation Path $path Interface $interface
................................................................................
        if {$noImplRemain} {
            relvar deleteone Path Name $path
            my TracePath removed $path
        }
    }
}
----





[source,tcl]
----
<<service methods>>=
method PropertiesChanged {eventInfo intfName changed invalidated} {
    set path [dict get $eventInfo path]
    dict for {propName propValue} $changed {

>
>
>
>
>
>
>
>
>
>
>







 







<
<
<
<
<
<
<
<
<
<
<











|
|
>













|
>







 







>
|
|
|
>
|
>







 







|



|







 







|
<







 







|







 







|
|







 







|







 







|
|





>













>
>
>
>



<
<
<
<
<





>
>
>
>
>





>
>







 







>
>









>
>


<
>
|


>
>
>













>
>
>
>
>
>

>
>
>






<
|







 







>
>
>
>
>







 







|



|


|
|









|

|





|



|







 







>
>
>







 







>
>
>







 







>
>
>







 







>
>
>







 







>
>
>
>







 







|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







>
>
>







 







>
>
>








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<







 







>
>
>







 







>
>
>
>
>
>







 







>
>
>
>
>







 







>
>
>
>




<







 







>
>
>







 







>
>
>
>







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
..
22
23
24
25
26
27
28











29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
...
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
...
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
...
302
303
304
305
306
307
308
309

310
311
312
313
314
315
316
...
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
...
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
....
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
....
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512





1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
....
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560

1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596

1597
1598
1599
1600
1601
1602
1603
1604
....
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
....
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
....
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
....
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
....
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
....
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
....
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
....
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
....
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
....
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
....
2576
2577
2578
2579
2580
2581
2582

































2583
2584
2585
2586
2587
2588
2589
....
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
....
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
....
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
....
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821

2822
2823
2824
2825
2826
2827
2828
....
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
....
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
== Package Overview

The `dbusclient` package is implemented as two classes using TclOO.
This means we need a relatively new version of Tcl.
Since we also tend to use the latest Tcl commands,
we'll insist upon the latest Tcl version (as of this writing).

[source,tcl]
----
<<required packages>>=
package require Tcl 8.6
----

The `dbusclient` package builds upon the Tcl bindings to DBus
contained in the
http://chiselapp.com/user/schelte/repository/dbus[`dbus`]
package by Schelte Bron.
The `dbus` package provides the fundamental interface to the
DBus ``C'' library used to access the DBus daemon.
................................................................................

[source,tcl]
----
<<required packages>>=
package require dbus
----












///////
----
<<man description>>=
[description]
This manpage describes the
[package dbusclient]
package which is a Tcl script extension that simplifies
client side programing for access to services on the DBus.
----
///////

There are two TclOO class commands in the packdage and they are exported from
the namespace and a namespace ensemble command is also created with them.

[source,tcl]
----
<<package exports>>=
namespace export Connection
namespace export Service
----

/////////
----
<<man commands section>>=

[section Commands]
The two TclOO class commands are exported from the [package dbusclient]
namespace and they form the subcommands of a namespace ensemble
on the [package ::dbusclient] namespace.
----
/////////

=== Connection class

The `Connection` class represents the communications connection to a
DBus daemon.
................................................................................
we want to make sure to destroy any services that may be using this connection.
So we have to iterate across any connected services.

[source,tcl]
----
<<connection methods>>=
destructor {
    try {
        foreach service [my FindConnectedServices] {
            $service destroy
        }
    } finally {
        ::dbus close $busId
    }
}
----

/////////
----
<<man connection methods>>=
[call [cmd "[arg connobj] destroy"]]
................................................................................
a method is a member of an interface that is supported by an object
instance.
Calling the method is a request to perform the function of the method.

The only complication here deals with the signature of the method.
The `dbus` package documentation describes the details of signatures in DBus,
but, as you might suspect, it is a means of dealing with DBus data typing
in the face of Tcl insisting that _everything is a string_.
We interpret an empty string signature as not wishing to pass in the
signature to the `dbus` command.
Later we will see that internally,
`Service` objects always supply the signature because it is
available from the service introspection.

[source,tcl]
----
<<connection methods>>=
method call {target path interface method sig args} {
    set cmd [list ::dbus call $busId -dest $target]
................................................................................
<<man connection methods>>=
[call [cmd "[arg connobj] filter"] [arg subcmd] [arg [opt "arg1 arg2 ..."]]]
----
/////////

=== Service class

The `Service` class represents a service provider on a DBus.

Server programs may connect to the DBus daemon and request a name for the
connection.
This name typically follows an inverted URI host name (_e.g._ com.example).
In DBus terms,
these are bus names and give the target to which service requests may be
directed.
You can think of bus names as being similar to _well known_ ports in
................................................................................
To know what objects and interfaces are supported by a service,
the objects of the service support the standard interface,
`org.freedesktop.DBus.Introspectable`.

By using the `Introspect` method in this interface it is possible to uncover
all the objects and interfaces supported by a service.
The `dbusclient` package caches this information to make various
tasks easier, such as immediate access to property values and keeping
track of property values when they change.
In this section,
we show a class diagram of the how the service metadata is held.

.Class Diagram for DBus Service Metadata
image::service-metadata.pdf[]

................................................................................
Better than just sandwiching a "/" between the path and its child node
name using sting concatenation.
<2> Here is the recursive introspection to obtain the information for
child nodes.

Once we know all the paths and interfaces in a service and know
which interfaces are implemented by which paths,
then we can create *PropertyValue* tuples for the properties that are
associated with a given path.
At this point,
we don't know the values of the properties,
so each property value is set to the empty string and marked as invalid.

[source,tcl]
----
<<service methods>>=
................................................................................
        relation restrictwith ~ {$Path eq $path} |
        relation list ~ Interface
    }]
}
----

For these tests, we want to be able to compare sets for equality.
Fortunately, `tcllib` provides all the needed commands and
`tcltest` allows us to define custom matching procedures.

.Tests

[source,tcl]
----
<<required packages for test>>=
................................................................................

==== A test server

It is convenient to put up our own service against which we can test.
Fortunately,
the [package dbif] package, also by Schelte Bron, provides some
convenient commands to do that.
In this section,
we show a test server build using the `dbif` package.
This server is then used for testing other parts of this package.

[source,tcl]
----
<<test-server.tcl>>=
#!/usr/bin/env tclsh
package require dbif

puts stderr "test server starting"

dbif connect -bus session -noqueue -replace com.modelrealization.test

<<test server methods>>
<<test server properties>>
<<test server signals>>

vwait forever
----

We include some methods that can be invoked on the server.
In particular,
we want to be able to exit programmaticallly.

[source,tcl]
----
<<test server methods>>=





dbif method /com/modelrealization/test Quit {
    dbif return $msgid {}
    puts stderr "test server exiting"
    exit
}

dbif method /com/modelrealization/test AddToCounter {cnt} {i} {
    incr ::Counter $cnt
    dbif return $msgid $::Counter
}

dbif method /com/modelrealization/test Trigger {
    dbif generate $::AttnSigId
}
----

We also add some properties that can be accessed.

[source,tcl]
----
<<test server properties>>=
dbif property -attributes {Property.EmitsChangedSignal true}\
        /com/modelrealization/test Counter:i Counter
set ::Counter 0
................................................................................
set ::Name "Test Server"

dbif property -access read\
        /com/modelrealization/test Source:s Source
set ::Source "Model Realization"
----

And finally, a signal that can be sent to a client.

[source,tcl]
----
<<test server signals>>=
set ::AttnSigId [dbif signal /com/modelrealization/test Attention\
        {Count:i Identity:s} {} {
    return [list $::Counter $::Source]
}]
----

The test service is started by the setup portion of the test script.

[source,tcl]
----

<<test server setup>>=
exec ./test-server.tcl &
----

To clean up the server,
we can call its `Quit` method to force an exit.

[source,tcl]
----
<<test utilities>>=
proc killServer {} {
    set conn [Connection create sessionBus session]
    Service create tserver com.modelrealization.test $conn
    tserver call /com/modelrealization/test com.modelrealization.test\
            Quit

    $conn destroy
}
----

[source,tcl]
----
<<test server cleanup>>=
killServer
----

==== Calling methods

One of the primary activities to perform on a service is to
call one of its methods.

[source,tcl]
----
<<service methods>>=
method call {path interface method args} {
    my ValidateCall $path $interface $method $args

    my variable connId svcName
    tailcall $connId call $svcName $path $interface $method\
        [my methodSignature $interface $method] {*}$args
}
----

.Tests

................................................................................
in [arg interface] on the the object specified by [arg path].
Additional optional [arg argN] arguments are passes as arguments to
the called method.
The return value of the [method call] method is the return value of
the underlying service method from the DBus.
----
/////////

We use the metadata that we have collected about the service through
introspection to validate the method call.
We do this before attempting the call itself in the hope to get
better error messages on this side of the interface to the DBus.

[source,tcl]
----
<<service methods>>=
method ValidateCall {path interface method arglist} {
    my ValidatePath $path
    my ValidateInterface $path $interface
................................................................................
/////////

==== Tracing properties and signals

Services on the DBus usually implement asynchronous notifications when
a property value is changed or when new paths and interfaces are
added or removed.
The `dbusclient` package handles these asynchronous notifications and
updates the values in the service metadata if the Tcl event loop is entered.
The package also provides an interface to allow programs using
[package dbusclient] to be informed of the changes.
This is accomplished by _tracing_ the various aspects
of the DBus service.

The tracing supported by `dbusclient` has an interface modeled
after the Tcl core *trace* command.
For the DBus,
we can trace on properties, signals or paths.

The following is a class diagram of the metadata that is held
to support tracing of DBus entities.

.Class Diagram for Tracing Metadata
image::trace-metadata.pdf[]

The diagram shows that there are three types of traces (*R7*).
Each trace has an identifier, a path matching pattern and a command prefix.
The path matching pattern is specified as in the *string match* command
and qualifies traces to the path names they must match.
The command prefix is executed when the DBus send an asynchronous notification
and the conditions of the trace are matched.
Property traces are further qualified by the interface and property name
that is traced.
Similarly, signal traces are qualified by the interface and signal name
they must match.
In both cases,
property traces and signal traces must be related to a property or
signal defined by an interface (*R8* and *R9*).

Following the pattern we used for service metadata,
the previous diagram can be rendered as TclRAL `relvar` commands
to establish the trace metadata schema.

[source,tcl]
----
................................................................................
        Signal {Interface Name} 1

relvar association R9\
        PropertyTrace {Interface Property} *\
        Property {Interface Name} 1
----

The `trace` method determines which type of trace operation is
requested and delegates the operation on to another method.

[source,tcl]
----
<<service methods>>=
method trace {operation args} {
    switch -exact $operation {
        add {
            set result [my AddTrace $args]
................................................................................
                expected add, remove or info"
            throw [list TRACE UNKNOWNOP $msg] $msg
        }
    }
    return $result
}
----

The `AddTrace` method determines the type of trace to be added and
further delegates the work onward to a trace type specific method.

[source,tcl]
----
<<service methods>>=
method AddTrace {argList} {
    if {[llength $argList] < 2} {
        set msg "wrong # of args, expected: trace add tracetype args"
................................................................................
            throw [list TRACE UNKNOWNTYPE $msg] $msg
        }
    }

    return $traceid
}
----

Method for the specific types of traces simply create
new tuples in the relvars for *R7*.

[source,tcl]
----
<<service methods>>=
method AddPathTrace {argList} {
    if {[llength $argList] != 2} {
        set msg "wrong # of args, expected: trace add path\
................................................................................
        ]
    }

    return $traceNumber
}
----

Removing a trace is somewhat easier since we can simply
remove the generalization instances from *R7*.

[source,tcl]
----
<<service methods>>=
method RmTrace {traceid} {
    set trace [pipe {
        relvar restrictone Trace TraceId $traceid |
        rvajoin ~ [relvar set PathTrace] Path |
................................................................................
        }
    }
    return
}
----
<1> Remove any bus message listening associated with the signal.

Finally,
introspection on traces is also just querying the *R7* generalization
and returning the attribute values.

[source,tcl]
----
<<service methods>>=
method InfoTrace {traceid} {
    set trace [pipe {
        relvar restrictone Trace TraceId $traceid |
        rvajoin ~ [relvar set PathTrace] Path |
................................................................................

For [var path] type traces no additional information is provided.

[list_end]
----
/////////

==== Synchronizing to changes

In certain coding situations, _e.g._ sequencing tests,
it is convenient to keep the code path sequential.
This requires performing operations and then entering the event loop
so that asynchronous updates from the DBus can arrive.

The general scheme is:

. Add a trace for the entity of interest.
. Execute a command that triggers some asynchronous response.
. Enter the Tcl event loop to wait for the response or potentially a timeout.
. Remove the trace.

This set of actions has been factored into methods to ease the
tedium of repeatedly coding the sequence.
There are separate methods for properties, paths and signals.
Note that these methods only support waiting for a single trace.
More complicated logical combinations will have to be coded.

[source,tcl]
----
<<service methods>>=
method waitForProperty {interface property pathpattern trigger {timeout 5000}} {
    set timerid {}
    if {$timeout != 0} {
................................................................................
[def value]
The new value of the property if the status element has a value of
[cmd changed].
[list_end]
----
/////////

The `PropertySync` method is invoked by the property trace
and stores a result dictionary into the variable used for synchronization.

[source,tcl]
----
<<service methods>>=
method PropertySync {status path interface property value} {
    set [my varname propSync] [dict create\
        status $status\
        path $path\
................................................................................
        property $property\
        value $value\
    ]
    return
}
----

Usually there is a timeout placed on waiting.
The `PropertySyncTimeout` method handles the timeout case.

[source,tcl]
----
<<service methods>>=
method PropertySyncTimeout {} {
    set [my varname propSync] TIMEOUT
    return
}
----

Waiting for signals or paths follows the same general pattern.
The differences are mainly in how the interactions are specified.

[source,tcl]
----
<<service methods>>=
method waitForSignal {interface signal pathpattern trigger {timeout 5000}} {
    set timerid {}
    if {$timeout != 0} {
        set timerid [::after $timeout [mymethod SignalSyncTimeout]]
    }
    set traceId [my trace add signal $interface $signal $pathpattern\
            [mymethod SignalSync]]
    try {
        set result [uplevel 1 $trigger]

        vwait [my varname sigSync]
        if {$timerid ne {}} {
            ::after cancel $timerid
        }
    } on error {result opts} {
        return -options $opts $result
    } finally {
        my trace remove $traceId
    }

    variable sigSync
    if {$sigSync eq "TIMEOUT"} {
        set msg "timed out waiting for signal change: $interface $signal\
                $pathpattern $trigger"
        throw [list SIGNAL TIMEOUT $msg] $msg
    }
    return $sigSync
}
----

/////////
----
<<man service methods>>=
[call [cmd "[arg svcobj] waitForSignal"] [arg interface] [arg signal]\
    [arg pathpattern] [arg trigger] [arg [opt timeout]]]

................................................................................
The argument signature of the signal.
[def args]
A list of argument values that came with the signal.
[list_end]
----
/////////


































[source,tcl]
----
<<service tests>>=
test signal-1.0 {
    Wait for a signal
} -setup {
    set conn [Connection create sessionBus session]
................................................................................
<<service methods>>=
method SignalSyncTimeout {} {
    set [my varname sigSync] TIMEOUT
    return
}
----

Path tracing is the simplest.
Here we are only concerned about a patter to match a path name.

[source,tcl]
----
<<service methods>>=
method waitForPath {pathpattern trigger {timeout 5000}} {
    set timerid {}
    if {$timeout != 0} {
        set timerid [::after $timeout [mymethod PathSyncTimeout]]
................................................................................
    set [my varname pathSync] TIMEOUT
    return
}
----

==== Callbacks for signals

The methods in this section are helpers to deal with various callbacks
that come up from the DBus.
These callbacks are used to find and evaluate any registered traces.

All signal callbacks result in invoking the `HandleSignals` method.

[source,tcl]
----
<<service methods>>=
method HandleSignals {eventInfo args} {
    log::debug [info level 0]
    set interface [dict get $eventInfo interface]
    set signal [dict get $eventInfo member]
................................................................................
    set path [dict get $eventInfo path]

    my EvalTrace signal {$Interface eq $interface &&\
            $Signal eq $signal &&\
            [string match $PathMatch $path]} $eventInfo {*}$args
}
----

Traces are looked up and evaluated in the `EvalTrace` method.
Here we see the logic of executing traces from youngest to oldest
and the logic associated with handling errors and early termination of
a chain of traces.

[source,tcl]
----
<<service methods>>=
method EvalTrace {tracetype predicate args} {
    set typeMap [dict create\
        path PathTrace\
................................................................................
[source,tcl]
----
<<service methods>>=
method TracePath {status path} {
    my EvalTrace path {[string match $PathMatch $path]} $status $path
}
----

The `InterfacesAdded` method is specifically used for the
callback resulting from a signal from the org.freedesktop.DBus.ObjectManager
interface.

[source,tcl]
----
<<service methods>>=

method InterfacesAdded {eventInfo path interfaces} {
    relvar eval {
        dict for {interface properties} $interfaces {
            set added [my AddNewInterface $interface $path]
            if {!$added} {
                # At this point we failed to find the interface
                # in the introspection XML. The best we can do
................................................................................
    if {[relation isempty $pathRel]} {
        relvar insert Path [list Name $path]
        my TracePath added $path
    }
}
----

Again the org.freedesktop.DBus.ObjectManager interface
has a specified signal to indicate when interfaces have been removed.

[source,tcl]
----
<<service methods>>=
method InterfacesRemoved {eventInfo path interfaces} {
    relvar eval {
        foreach interface $interfaces {
            relvar deleteone Implementation Path $path Interface $interface
................................................................................
        if {$noImplRemain} {
            relvar deleteone Path Name $path
            my TracePath removed $path
        }
    }
}
----

Another common interface is org.freedesktop.DBus.Properties.
It also has a signal to indicate that a property on an interface has
either changed value or is now invalid.

[source,tcl]
----
<<service methods>>=
method PropertiesChanged {eventInfo intfName changed invalidated} {
    set path [dict get $eventInfo path]
    dict for {propName propValue} $changed {