On Fri, 25 Feb 2000, Andre Poenitz wrote:
> > 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.
>
> I don't agree. Sorry... (Erm... well, it's friday, isn't it)
>
> String parsing is not error prone once you got it nicely encapsulated.
> And that's really not too difficult.
>
> String parsing is slow. But that does not matter in our context. We want
> a "real time _user_ interface", i.e. on one end of the interface sits a
> human. And this human is the weak link performance-wise.
Recall that Asger has already memntioned the text export and that XTL
supports several other formats for externalization (CORBA stuff and XDR).
If you really, really wanted to you could write support for another format
that could be XML-like. This would be a string input and output that
could then be used to support all the external scripting languages or
other client programs you could imagine.
> > The XTL library solves this problem for us in a clean, efficient, elegant,
> > and extensible way.
>
> This introduces another bit of software that deals with binary data.
And text data and any other format you care to define.
> > 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.
>
> So can a string interface. UNIX external stuff tends to be plain ASCII.
> It's easy to debug, it's easy to control with standard tools.
And with an XTL-based string format we don't have to write or maintain new
parser databases for each new object/structure we want to communicate. In
fact XTL makes it very easy for us to use the exact same code to
communicate in different formats (be it a string, raw binary, or CORBA
GIOP IIXYZ whatever the acronym is).
[... strings + streams sample code...]
> I don't think, this will be possible.
You're right ;-)
Allan. (ARRae)
