On Fri, 13 Oct 2000, Andre Poenitz wrote:
> > Am I right in saying that together they effectively give us the functionality
> > of XTL? Or am I getting excited and being stupid at the same time?
>
> No, that's basically what XTL would do - at least in this place.
>
> And the idea to use strings in these places is not really new, either.
> IIRC the last proposal to use XTL was more or less a direct reaction to
> this idea, based on the (unvalidated and IMNSHO unjustified) assumption
> that using strings might be too slow.
And also a round about way of doing it. XTL allows a much simpler way
(from the users point of view) of externalising arbitrary objects.
I had always said we needed an XTL that could export to string/XML format
and back again so we can use the same code to save/load lyx files, talk to
lyxfunc and the gui. XTL's TextFormat externaliser was a one way process
so we used a binary externaliser (using a raw format initially and then
switching to GIOP and XDR). I made lots of noise about needing a reverse
conversion from TextFormat but never got around to implementing it --
partly due to limited time and partly because XTL just put too high a
demand on the commonly available compilers -- otherwise we would have had
a simple, useful, single-string solution for passing arguements to
LyXFunc.
There is more to externalising than speed. There's also convenience and
maintainability and IMNSHO that outways converting everything to a
_single_ string by hand as was originally proposed (it was also the main
reason for rejecting your string proposal in the first place; speed was
just another consideration). With regard to the speed arguement though,
when using a single string there is the added costs of parsing which Lars'
solution, FuncSlot, avoids since all argements must conform to some
preordained order.
You would have done better to argue for a strstream solution in your
original proposal so we could just add a strstream operator<< and
operator>> for data objects like PrinterParams etc. At the time I
was unaware of strstream and it now seems stringstream is the current
fashion.
> Anyway. Nice to see you arriving there.
Strings (plural) are fine but it's how we implement the getting to and
from strings that is important. In stream_cast<> and Lars' FuncSlot we
finally have an alternate solution to XTL.
We can simulate some of the capabilities of XTL using our own
serialisation code based on stream_cast<>. This will probably prove
adequate for most purposes but Lars' example code doesn't convince me it's
capable of doing all the stuff XTL is capable of. I also think we'll end
up writing about three times as much code using stream_cast<> and FuncSlot
as XTL would require (although it'll be less than converting everything by
hand... perhaps). However, stream_cast<> has the advantage that it works
on most if not all compilers now, whereas XTL only works on a few
compilers now.
XTL is still the better solution because it would also allow us to support
CORBA services by simply externalising to the CORBA format GIOP and
because it is more convenient to use. With XTL you can also write one
function that does both import and export -- this might be possible by
using templates in the manner that XTL does but you end up somewhere
having to write a support class that is a string/stream specialised
version of XTL. That could be much simpler than the current XTL and as a
result able to be compiled on just about any compiler.
##
Lars' why not just use stringstream as the parameter for dispatch()? You
can build all the stuff you want by hand then and we can write two
operator functions to support [de]serialising any given data object like
PrinterParams?
We still don't get compile-time type-checking to match arguements to the
requirements of a given LFUN but it's flexible. We'd need a version
number for the data so that older apps can still talk to LyX after we add
or delete a variable from the data structure. We could add the type_info
within the operator<< like this to get some extra checking (assuming my
imagined stream operators exist) or just use a string name:
stringstream & operator<< (stringstream & ss, PrinterParams const & pp)
{
// can we export type_info to a stream?
return ss << type_info(pp)
<< pp.version
<< pp.var1
...
<< pp.varN;
}
stringstream & operator>> (stringstream & ss, PrinterParams & pp)
{
Assert (ss[0] == type_info(pp))
// how do you extract the type_info from a stream?
// how do you pop the first element from a stream
// and specify its type
switch ss[1] {
case 0:
return ss >> pp.var1
...
>> pp.varN;
break;
case 1:
// set missing parameters to default values then
// read the known values
return ss >> pp.varX
...
>> pp.varY;
break;
default:
Assert(false);
// unknown or unsupported format
break;
}
}
If you wanted to use XML so you could use the same operators to write .lyx
files you could add some pretty
<< "varname1=\""
...
<< "\" varnameI=\""
...
<< '"';
lines as well. Assuming it's possible to write type_info to a stringstream
then you could add a switch statement in the file reader to read
particular data based on type_info (perhaps).
XTL still does this stuff much more simply.
Allan. (ARRae)
P.S. I see you wrote this on Friday so I guess I've taken your flame bait
