|
1 DOCUMENTATION: |
|
2 |
|
3 I: Jingle |
|
4 Jingle is a module who can't work alone. His meaning of life is make working |
|
5 others modules. There is two sorts of modules: applications (File Transfer, Voice) |
|
6 and transports (IBB, socks5, ...). |
|
7 The "sub-modules" must register in jingle and provide some generic function. |
|
8 After the jingle module catch and dispatch all jingle's iqs. And offer an |
|
9 interface between apps and trans. |
|
10 Jingle module keep a way of all sessions via JingleSession structures. |
|
11 This JingleSession got all the informations and a list of SessionContent, which |
|
12 are struct containing information about content and 2 gconstpointer. This pointer |
|
13 are data from apps and trans. |
|
14 |
|
15 An application module must provide: |
|
16 - check: check if the description of a JingleContent is correct; |
|
17 - handle: each application have some options not conventional, so handle is the |
|
18 less option. We give him all the jingle iqs than other function doesn't |
|
19 handle; |
|
20 - tomessage: add the gconstpointer to a given node; |
|
21 - handle_data: when the peer send data to us, the trans module catch it and |
|
22 give it to jingle. After jingle give it to the apps via this |
|
23 function; |
|
24 - start: the session have been accepted we can init our transfer; |
|
25 - send: it's call until there is datas to send; |
|
26 - stop: we've got a session-terminate, we need to close transfer, files, ... |
|
27 |
|
28 An transport module must provide: |
|
29 - check: the same as application; |
|
30 - tomessage: idem; |
|
31 - cmp: to know if 2 transports are the same. Use by IBB, when we got |
|
32 a new data jingle must look the gconstpointer to got the ibb-id to know |
|
33 which apps is concerned; |
|
34 - xmlns: util when we got only funcs, to know who are we; |
|
35 - new: to create a new transport node, with default options; |
|
36 -send: to send data given by apps via jingle. |