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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
This is a more or less incomplete list of more or less independant tasks that
would be nice to have done for the first stable release.
Performance (Some ideas to improve performance, profile to verify!):
* callgrind suggests g_object_new requires much time, especially for objects
that are often instantianted, such as InfAdoptedRequest,
InfTextDefaultInsertOperation and InfTextDefaultDeleteOperation. Maybe we
can improve this by not initializing the member variables by properties,
but by setting them after the g_object_new() call.
* Move state vector helper functions in algorithm to InfAdoptedStateVector,
with a better O(n) implementation.
* Cache request.vector[request.user] in every request, this seems to be
used pretty often.
* There is already a function for this, inf_adopted_request_get_index()
* It needs to be consistently used where this information is required
* And then the cache actually be introduced
* Optionally compile with
- G_DISABLE_CAST_CHECKS
- G_DISABLE_ASSERT
- G_DISABLE_CHECKS
defined.
Modernization:
* Use G_TYPE_ERROR for signals with an error parameter
and G_TYPE_ARRAY for InfdSessionProxy::block-user-join
* ffi marshalling
* Phase-out GTK2 support
* Use g_get_monotonic_time/g_get_real_time where a time is needed
* Generate gobject introspection annotations, typelibs and girs
* Use GFile API for InfdFilesystemStorage
* Use G_DEFINE_TYPE and friends
* Replace constructor by constructed
* Use GtkBox and GtkGrid, use GtkBuilder for widgets/dialogs
* g_set_error_literal
Protocol Break:
The following features would be nice to have, but they require breaking
the protocol. Maybe it could be introduced such that new clients can still
talk to old servers.
* Change the transformation function such that all text that starts with a
newline character is transformed to the right when two insert operations
are at the same location. This would allow people to create a new line at
the end of the line where someone else is currently typing while not
interrupting their workflow. It would also making the linekeeper plugin
safe from such conflicts. If we do this, we also need to add some unit
tests in test/session which check that it is implemented correctly.
Others:
* Split InfXmppConnection (XMPP)
- InfXmppConnection: XMPP core implementation
- InfJabberConnection: Connection to jabber server, managing roster, presence, etc. Derives from InfXmppConnection, not used on server side
- InfRawXmppConnection: InfXmlConnection implementation by sending raw messages to XMPP server (Derive from InfXmppConnection, make XMPP server create these connections (unsure: rather add a vfunc and subclass InfXmppServer?))
- InfJabberUserConnection: Implements InfXmlConnection by sending stuff to a particular Jabber user (owns InfJabberConnection)
- InfJabberDiscovery (owns InfJabberConnection)
* Make InfTextChunk reference-counted, or implement copy-on-write semantics. It is currently copied way too often. (InfText)
* Implement inf_text_chunk_insert_substring, and make use in InfTextDeleteOperation (InfText)
* Add a set_caret paramater to insert_text and erase_text of InfTextBuffer and derive a InfTextRequest with a "set-caret" flag.
* InfTextEncoding boxed type
* Create a pseudo XML connection implementation, re-enable INF_IS_XML_CONNECTION check in inf_net_object_received
* Add accessor API in InfGtkBrowserModel, so InfGtkBrowserView does not need to call gtk_tree_model_get all the time (which unnecssarily dups/refs)
* Add append() and clear() virtual methods to InfTextBuffer. These may not have to be implemented since a default implementation can be used if no special one is provided, but it could help to speed up special operations. Make use in infd_note_plugin_text.
* Allow split-operations of insert and delete operations to be made in one go, to atomically modify the document at many places at once
* This can be used between begin-user-action and end-user-action, to keep the operation atomic on the infinote side
* maybe need to evaluate whether a split operation which has insert as one child and delete as other child is handled correctly
* definitely add more unit tests for this
* Make InfLocalPublisher take a InfdXmlServer instead of a port number. Maybe
even rename to InfPublisher, with InfDiscoveryAvahi assuming an
InfdXmppServer. Or, consider simply removing the interface, and require
people to use InfDiscoveryAvahi directly (check how well that works with
InfdServerPool).
* Make a InfcChat object that handles the chat session from InfcBrowser.
InfcBrowser should relay messages to it, and if not handled by InfcChat,
handle it by itself. InfcChat should be a public property of InfcBrowser,
but handle all the chat stuff itself. Maybe implement
InfCommunicationObject and still have the stuff relayed? Check again how
the InfcBrowser->InfcSessionProxy->InfSession flow goes and do the same.
* The same kind of thing should be implemented on the server side.
* Make a common InfBrowserTree class which implements the basic tree structure
commonly on client and server side.
* Remove infc_browser_get_status() function
* Change the storage interface to be asynchronous
* take the chance and require gio
* port the network code to gnio?
* Also create InfcRequests for remotely triggered actions that do not come
with a local request. Such requests would have the "seq" property set to
some invalid value. Basically all operations made should have a request
for them, the parameter should never be NULL.
|
