Roadmap for Gammu
There are some major issues which should be addressed in Gammu soon. This list is not sorted at all, but includes bad design decisions made in Gammu past which we would like to fix.
One problem is locations handling, because current scheme (using numbers) really does not match majority of current phones and it should be converted to using path based locations for messages, phonebook, calendar, etc.
The another major obstacle which is all around Gammu code is own implementation of unicode (UCS-2-BE) strings. This code should be dropped and use some standard library for that. Note that wchar_t is probably not a good choice here as it’s 16-bit on Windows and thus can not store emojis and other supplemental plan unicode chars.
Hardcoded length for strings
Most of the strings have hardcoded length limits. This limitation should be removed and strings allocated on the fly.
Unsigned char mess
In many cases
unsigned char is used without any reason.
Extensibility of libGammu
Current way of adding protocol specific functionality from applications using libGammu is broken. Actually only application using this is Gammu utility. This option should be either completely removed or rewritten from scratch not to be dependent on libGammu internals.
Built time configuration
Avoid heavy usage of gsmstate.h header and move the
#ifdef...#define...#endif blocks to
gammu-config.h. Or rather cleanup
them and have only single define for single compile time option.
Config file handling
Drop multiple configurations handling in libGammu, it should provide just API to read some section from Gammurc and possible fall-back logic should be in application.
There should be simpler way to generate AT command with proper escaping and charset conversion of fields. Something like reverse ATGEN_ParseReply.