Georg Baum wrote:
Richard Heck wrote
Well, there are advantages to the serialization. I can't remember what
they are ;-), but I have seen them.
It is a type question. Passing InsetFooParams directly would mean that the
dispatch mechanism needs to know about all these types, or rather you need
a way to encapsulate them since it is probably not a good idea if some
generic code has to care for the types.
Yes.
That said, this is the normal flow
from controller to core: The controller has a copy of
InsetCommandParams; it wants to pass that information upstream to the
inset. So what it does is serialize them, call an LFUN, and then the
kernel reads the stream back into an InsetCommandParams. So you have to
do it this way if you want to use dispatch, etc, rather than some sort
of direct interaction with the kernel. I'd have to look a lot more
closely to see what that would be like exactly. But surely there's some
way to just hand the inset its new parameters.
Of course, but I guess implementing that would not be trivial.
I'm sure, for largely the type-related reasons you mentioned above.
All in all I
think that serialization is not bad at all, since it allows to handle some
aspects of kernel<->frontend interaction centrally, and more importantly,
offers a possibility for automation through the lyxserver. Only the current
implementation with the mailers is clumsy. If you had a serialization that
would not require to implement these wrapper classes for new insets and
that would 'just work' without additional effort (for example by using the
insets read() and write() methods directly), then I think this would be
ideal.
Not that I have time to do this now, but if you had any further ideas
about this, I'd love to hear them.
Richard
