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
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
