**What are we doing?**
We are moving towards stateless callbacks. This means that when registering a
callback, you no longer pass a user data pointer. Instead, you pass a user data
pointer to tox_iterate. This pointer is threaded through the code, passed to
each callback. The callback can modify the data pointed at. An extra indirection
will be needed if the pointer itself can change.
**Why?**
Currently, callbacks are registered with a user data pointer. This means the
library has N pointers for N different callbacks. These pointers need to be
managed by the client code. Managing the lifetime of the pointee can be
difficult. In C++, it takes special effort to ensure that the lifetime of user
data extends at least beyond the lifetime of the Tox instance. For other
languages, the situation is much worse. Java and other garbage collected
languages may move objects in memory, so the pointers are not stable. Tox4j goes
through a lot of effort to make the Java/Scala user experience a pleasant one by
keeping a global array of Tox+userdata on the C++ side, and communicating via
protobufs. A Haskell FFI would have to do similarly complex tricks.
Stateless callbacks ensure that a user data pointer only needs to live during a
single function call. This means that the user code (or language runtime) can
move the data around at will, as long as it sets the new location in the
callback.
**How?**
We are doing this change one callback at a time. After each callback, we ensure
that everything still works as expected. This means the toxcore change will
require 15 Pull Requests.
A couple of minor reasons, combined warrant a PR imo:
a) fileChunkRequested is a better signal name than fileRequestChunkReceived, and I don't want to break consistency by reordering words for just this signal
b) "request chunk" is parsed by English speakers as a verb-object combination,
implying sending the request, not receiving, whereas "chunk requested" is
parsed (more correctly) as an adjective-noun combo (in particular, request is
a noun not a verb), and thus reads far more like "hey heads up we just got a request"
For instance some tests/testing code had some callbacks to *receive* chunk requests, and they were called "tox_file_request_chunk"... to receive a chunk, not request it. Now they're called "tox_file_chunk_request".
So yeah...
file_id is a 32byte identifier that can be used by users to identify
file tranfers across core/client restarts in order to resume broken
file tranfers.
In avatar tranfers it corresponds to the hash of the avatar.
Added tox_file_get_file_id() function to api to obtain the file_id
of an ongoing file transfer.
If not set, core will generate a random one.
#if 0 the content of toxav/msi.c : int stringify_message(MSIMessage
*msg, char *dest)
This function has no effect and does not seem to be used for actively
waiting.
Fix various other style errors, reduce scope when possible, avoid
redundant writes, clarify operator priorities, etc.
Main changes:
1. Strings no longer need to be NULL terminated.
2. tox_get_friend_id is now named tox_get_friend_number.
3. The friend request callback function is now (Tox *tox, uint8_t *,
uint8_t *, uint16_t, void *), the Tox object pointer has been added to
it.
Crash stuff:
nTox.c:
- do_refresh(): avoid crashes (input a "%" and the client goes "boom!", send someone a string with embedded "%" and see him blow up...)
Other stuff:
toxcore: tox.h (doc.)/network.c (code):
- networking_wait_prepare(): return -1 if lenptr was NULL and therefore not settable
nTox.c:
- fraddr_to_str(): function to convert a TOX_FRIEND_ADDRESS into a segmented (and therefore line-breakable) string
- print_friendlist(): print index of friend on name line, print id on 2nd line
- command /f: skip spaces (and +) inside a friend id
- command /r (new): "/r #" to remove a friend
- main(): reduce cpu consumption if we're not currently sending files
