TODO

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.
    Can we make InfAdoptedRequest a boxed type?
  * 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.

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.

  * Add a rename functionality

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.
 * 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.
 * InfcBrowser and InfdDirectory have grown very large. This code should be
   refactored a bit, and allow plugins to dynamically add handling of
   network messages. Stuff like create-acl-account could then perhaps be
   delegated to the certificate-auth plugin... in that particular case maybe
   better a hook into the create_acl_account impl, but custom network messages
   might still be nice for git integration.
   * InfDirectoryTree: Implements the basic tree structure,
     with node management functions.
   * Inf(c)RemoteBrowser: Owns a InfDirectoryTree, implements the InfBrowser
     interface with a server connection.
   * Inf(d)StorageBrowser: Owns a InfDirectoryTree, implements the InfBrowser
     interface with a storage backend (--enable async storage backend here!).
   * Inf(d)Server: References a InfBrowser, and implements the networking
     on top of it. This approach would even allow implementing a "delegating"
     server which does not serve the content itself but actually asks another
     server, by using a InfRemoteBrowser as a backend.
 * Threading: Better support for multi-core CPUs, ideally by running each
   InfCommunicationGroup in a separate thread. Would need many adaptions in
   other code to be thread-safe.
 * OCSP: Server asks for OCSP status periodically, and delivers ocsp status
   if client asks for it. Client always asks for OCSP status, and fails the
   connection if no OCSP response is retrieved and OCSP MUST STAPLE is set in
   server's cert.