[XTL]
> I did that too and I admit I dont get what this is suposed to do for LyX? Do
> you intend to have a new file format?
> Btw XDR is a platform independent format for binary representation. I use
> XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with
> some automatized traversal, but what would that be needed for?
>
> Am I clueless or missing imagination here?
The problem XTL can solve is primarily the communication between the
LyX kernel in the form of the current LyXFunc and the front-ends.
This interface either has the form of a simple string interface now, much like
the minibuffer, or is non-existant.
The string interface is too simple for the kind of information that should
be passed around. We have considered extending the string interface
with various ways of encoding the information, but that would require
slow and error-prone parsing of strings.
The XTL library solves this problem for us in a clean, efficient, elegant,
and extensible way.
It even promises the perspective of easier interoperability with external
stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on
steroids.
In other words:
XTL can provide the medium of communication between the LyX kernel and
the rest of the world. Technically, we could use XTL to get a new
file format, but that's not relevant at this point in time.
For starters, we would probably only export the needed stuff for the
dialogs via XTL, and over time, more and more of the kernel can be
exported this way.
Anyway, that's how I thought the XTL could help LyX. Obviously, we
can live without XTL, but it makes life easier, because we don't have
to provide tons of interfaces into the kernel.
Instead, we just have to provide XTL memory pools for certain features
that contain potentially lots of parameters.
The neat part about XTL is obviously that you only have to implement
one method for each structure to get both read and write functionality.
Greets,
Asger
