Hi developers, I would like to let you know about API/ABI incompatibility on uim 1.5.0 and expected future change. Please let me know if something is bad.
There are only 3 categories and 5 entries of ABI-incompatible little libuim API changes. See doc/COMPATIBILITY for further information. http://uim.googlecode.com/svn/trunk/doc/COMPATIBILITY - API bug fixes * "Fix invalid type assumption on PIDs" * "Change return type of uim_set_candidate_selector_cb() to void" - non-core API removal * "uim_symbol_value_str removal" * "uim_iconv_open() privatization" - incompatible ABI changes * "Deprecation of UKey_Shift_key and so on" "API bug fixes" are required to fix invalid API definition about its types. But the API invocation will probably not affected. "non-core API removal" is aimed to make uim API set proper. Although we can keep them remained as deprecated API/ABI for backward compatibility, I simply removed them since: - libuim ABI is already incompatible because of the "API bug fixes". So we don't have the motivation to keep the ABI - Invocations of them should be replaced with more proper ones, to make libuim responsibility clear The change of "incompatible ABI changes" is just a enum renumbering. It is not required, but since libuim ABI is already incompatible because of the "API bug fixes", it is good time to renumber them. If you want to keep the API/ABI of "non-core API removal" and "incompatible ABI changes" remained for backward-compatibility, Please let me know the reason. In addition to libuim API/ABI changes, there are a lot of uim-scm API/ABI changes. - incompatible changes on uim-scm API/ABI * "uim-scm API reorganization in uim 1.5.0" * "uim-scm API truth predicates reorganization in uim 1.5.0" * "Bit width extension of uim_scm_c_bool() and uim_scm_make_bool()" But since they are regarded as semi-internal interfaces of uim, and declared as "unstable interfaces", I don't hesitate to revise them. And to make libuim ABI number inaffected from the uim-scm ABI changes, I'm going to separate uim-scm as libuim-scm from libuim in uim 1.5.0. After the libuim-scm separation, further API/ABI changes up to uim 2.0 are expected as follows: - Keep libuim-scm API/ABI unchanged on uim 2.0 - Change libuim API/ABIs step by step until uim 2.0, or at once on uim 2.0 * Remove uim_ipc_*() (misnamed: actually popen(3) like utility of uim) and turned it into a Scheme utility procedure * Replace Helper-protocol dependent and string-based "Property API" with pure C interface like "mode API" * Separate uim-helper facility and uim_helper_*() functions from libuim, and replaced with bridge-dependent IPC such as D-Bus on UNIX desktop, and no IPC on Qtopia * Replace im-switcher API with the "Property API" successor * Revise overall uim API on uim 2.0 Please let me know your opinion about it. If nobody objected, uim 2.0 may be reorganized as follows. But since keeping the libuim compatibility layer is painful, I want to select the strategy rewriting all bridges into libuim2-based, and discard the old interfaces. Please let me know if you have a reason to keep libuim compatibility provided even if all bridges are rewritten for the new interfaces. uim 1.5: +-------------------------+ | bridges | +-------------------------+ | libuim : uim-helper | <--> uim-helper-server +----------+--------------+ uim 2.0: +------------------------+ | new bridges | +-----------+--+---------+----------------------+ | libuim2 | | bridge-dependent IPC (D-Bus) | <--> a msg bus for uim +-----------+ +--------------------------------+ uim 2.0 (legacy interface): +----------------------------------+ | legacy bridges with uim-helper | +----------------------------------+ | libuim (compatibility layer) | <--> uim-helper-server +----------------------------------+ | libuim2 | +----------------------------------+ ------------------------------------------------ YAMAMOTO Kengo / YamaKen [EMAIL PROTECTED] FAMILY Given / Nick http://en.wikipedia.org/wiki/Japanese_name --~--~---------~--~----~------------~-------~--~----~ Google Groups "uim-en" group uim-en@googlegroups.com http://groups.google.com/group/uim-en/about -~----------~----~----~----~------~----~------~--~---
