Miciah Dashiel Butler Masters <[EMAIL PROTECTED]> writes: > It looks messy, but I don't know whether there is a better approach. > I'll need to think about it more. Of course, Jonas is the boss.
There are three reasons to have separate data formats for the interlink protocol and for internal use in the master. 1. It allows the internal representation to be changed without worrying about compatibility. 2. It is good to have UCS-4 in struct term_event, but compatibility with ELinks 0.11 requires the interlink protocol to carry individual bytes, so using the same structures could be confusing. Instead of defining a whole separate struct interlink_event, this issue could also be solved by defining just a new event type for Unicode keyboard events, and a new structure in the term_event.info union. However, that would require the structure to be kept small enough so that the size of the union does not change. When the interlink protocol is eventually changed (bug 793), this reason will no longer apply. Instead... 3. The next version of the interlink protocol could even be made platform-independent, so that ELinks processes running on different platforms could communicate with each other. This will be useful if there are 32-bit and 64-bit processes running on the same machine, or if a network file system allows AF_UNIX sockets to be contacted remotely. > What if we introduced a separate routine to convert term_event > to interlink_event, so as to minimise change to handle_interlink_event? I don't see how that would help, as handle_interlink_event converts From interlink_event to term_event, rather than vice versa. > Why don't you use set_init_term_event? Will do.
pgpP6w9yZ3PE0.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
