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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
Interface to Telepathy Tubes.
The idea is to provide 1-1 collaboration between contacts and many-many
collaboration via MUCs, using Telepathy DBus Tubes over Jabber/XMPP.
First stab is at 1-1 contact channels, hopefully MUCs can be realized using
the same TeleConference abstraction.
To enable configure LibO with --enable-telepathy
Status 2012-03-16:
* no LibO code depends on this module yet, so it is not built in a regular
build, even if configured with --enable-telepathy, so cd tubes and make here
* to enable the various SAL_INFO and SAL_WARN messages emitted during
cppunittest pass SAL_LOG=... and do a debug build
* SAL_LOG="+WARN+INFO.tubes" make -rs debug=true
* the cppunittest will currently fail anyway (even if it wouldn't for other
reasons), this is on purpose to be able to see the output as otherwise it
is silenced down ... :-(
* for the cppunittest needed:
* a jabber daemon running on localhost.localdomain
* two accounts configured in Empathy
* libo1@localhost.localdomain
* libo2@localhost.localdomain
* libo1 and libo2 must be contacts/buddies of each other
* both accounts need to be online in Empathy
* very nasty GMainLoop handling for cppunittest, MAYBE we could get rid of
that in a real LibO, this might be responsible for some ugly behaviour
* contact channels seem to be successfully setup
* the client's callback TeleManager_DBusChannelHandler setup with
TeleManager::connect() does not appear to get ever called
* hence the tube offer triggered by TeleManager_ChannelReadyHandler is never
accepted
* unsure if the uniquify setup with tp_simple_handler_new_with_factory() would
work at all, hence trying to have one instance un-uniquified, but to no
avail
TODOs (once those basic problems are solved)
* associate a document with a conference
* use SfxObjectShell as an abstraction and broadcast incoming changes?
* use UNO API?
* first setup just to get something working could share a document
accessible by all parties on a network share or some such
* may need one master responsible to save the document
* later document transfer will be needed, use Telepathy File Transfer
* dialog to pick own account
* dialog to pick contact or MUC to work with
* dialog to accept/reject collaboration requests
In applications, e.g. Calc:
* stricter model,view,controller
* disable all actions we cannot process collaboratively
* separate input from view
* preprocess input to determine data type (text, number, date, ...)
* send typed/categorized data over wire before actually processing in model
* process serialized input as received
* Calc specific:
* use existing shared document feature with change-tracking enabled to
visualize changes
* may have the benefit of having already only a subset of trackable change
actions available
* let ScDocFunc handle also received changes
* have dialogs send their result item sets over the wire
|
