On Mon, Sep 24, 2007 at 09:23:01AM +0200, Georg Baum wrote: > Richard Heck wrote: > > >>> In the end, I don't think this will be needed. But yes, the > >>> serialization here is a hassle, and it's sheer luck that it isn't a > >>> problem. > >>> > >> How would an optimal/a better solution look like in your opinion? > >> [Serious question] > >> > > 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.
Why do we need the dispatch mechanism for calls into the kernel? > Of course, but I guess implementing that would not be trivial. 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. The lyxserver is used only for a few very specific functions. We can have a separate entrypoint for them. > 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. Even if there was a three line solution for that problem (and there is actually, Q_DECLARE_METATYPE + QVariant::fromValue + QVariant::value) it's probably nothing I'd suggest to use as "direct access" to the kernel does not sound wrong. Reality check: How do you access libc functions? By serializing calls to dup2 or fork? Nah... Andre'
