> The string interface is too simple for the kind of information that should
> be passed around.
What kind of information can not be passed around as strings?
> 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.
As long as you do not pass lots and lots of internal calls through this
interface that's just fine. And LyX does not do that currently. Even if
LyX becomes more modular and some internal calls could be made through
this interface, this won't become overwhelming. After all, it's modular
then...
> 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.
> 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.
> can live without XTL, but it makes life easier, because we don't have
> to provide tons of interfaces into the kernel.
Tons of interfaces?
> Instead, we just have to provide XTL memory pools for certain features
> that contain potentially lots of parameters.
If we really need that we should have a stream interface.
Send a command/parameter stream in and wait until something comes out
the result stream or on the error stream.
Conversion of strings and stream is niot difficult, too...
> 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.
Do you think this will be much easier than:
function(istream & inputstream, ostream & outputstream, ostream & err.. )
{
int par1, par2;
inputstream >> par1 >> par2;
if (!inputstream) {
errorstream << "funny parameters";
return;
}
outputstream << "some rtesult";
}
I don't think, this will be possible.
Regards,
Andre'
--
André Pönitz ......................... [EMAIL PROTECTED]
