Meanwhile 1.0.2 works. However, there are some things that annoy me. This is what happens in any project that slowly grows to include features, and I'd imagine is especially common in projects which reverse engineer protocols or formats. New information appears regarding how things really work, and the design mutates. Later, you see all sorts of refactoring possibilities and you start to wonder if maybe a full re-write isn't such a bad idea. And so, here are the plans for Meanwhile 2.0
See Meanwhile 2.0 Progress for a record of how far along things are.
Port the instantiatable structures to GObject types. Use signals instead of handler structures.
Don't let a single channel starve other channels. Enqueue outgoing channel messages on the channel instance, and mark the channel as having outgoing data pending. Let the session iterate over pending channels, handling one message at a time from each channel in a circular list. Give session messages priority over channel messages.
The parsing code for incoming messages currently lives in session.c, and is a little ugly. Let's change this by creating a mw_parser, which is simply fed with data asynchronously, and as full messages arrive, have it trigger a callback specified at creation. This means many of the proxy samples can be greatly simplified, and around 200 lines of code can be cut out of session.c
The queue for outgoing messages could lead to a lot of alloc/free if we used a regular GList structure. Perhaps create a mw_queue, which can be instantiated with a type size, and initial and grow counts. As new items need to be enqueued, receive a pointer to a correctly sized structure via push() and fill its members as necessary. When pop() is called, the data from that structure will be returned, and the structure will be marked as available for re-use by another push call. In implementation, it's just a circular buffer.
It should be possible to add another cipher to channel encryption offers. This would allow any Meanwhile 2.0 client to use blowfish to any other Meanwhile 2.0 client.
OTR or GPG Key management
Signing messages, or basing shared key negotiation on GPG. Requests for key signing, etc in a custom Sametime client service.
Since we're tied to GLib so strongly, why not use it more directly? GIOSession makes use of the glib event loop and GIOChannel signals to automatically perform reads/writes to a socket.
Rather than having the session feed incoming channels to a single service matching an ID, have the service(s) watch the session for an incoming channel event. If the service wants the channel, based on the channel instance itself, it can claim it and the signal emission stops. This allows more than one service to listen for the same channel service ID, but allows it to differentiate based on other factors (such as type or version, or information embedded in the offered additional-info opaque).
If no service wants the channel, then it can be automatically closed at the end of the signal emission. This cuts out a chunk of code from every outgoing-only service (storage, resolve, aware, directory)
Also, let's rename the services to put the adjective(s) before the noun.
Direct File Transfer Service
Subclass of File Transfer that allows both traditional in-channel transfers, and direct client-to-client transfers. Possibly allow entire directories to be shared. I wonder if it would be possible to seed a torrent over a service... hrm.
NotesBuddy IM Service
Clear the NotesBuddy features out of the IM service and into a subclass. Let it watch for channels with the appropriate tagging.
Extended IM Service
Implement the IM Service Extension I've been thinking about.
Actually implement this thing, finally.
Use the GLib base types where possible (gchar, guchar, gconstpointer, etc). Typedef structures from a form mw_struct_name to MwStructName. Use const where appropriate.