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. That said, this is the normal flow
from controller to core: The controller has a copy of
InsetCommandParams;
Which should be converted to direct const ref access IMO. While the idea
of transmitting objects in the network or between process could seem
sexy, it involves too much maintenance hassle and the resulting class
are very rigid because of that. So, all serialization should be removed.
The same death sentence should be pronounced to the diverse
InsetMailers. An Inset shall not have *any* knowledge about the
frontend, I mean _at all_.
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.
An LFUN should be as simple as possible. Encapsulating (i.e.
serializing) a full InsetCommandParams in a string is very wrong to
start with. A proper protocol should be designed in order to cover all
possible option.
LFUN_COMMAND command option1 option2 ...
I can't see why this would not be sufficient.
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.
That would be an option too but I am afraid this tower is too big ;-)
Let's try to proceed to the first step first: eliminates the
serialization from the core to the frontend and all associated mailers.
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.
We discussed that many times already and I think we agree on the way
forward (at least you and me ;-)). So I'd support every move you make in
this direction. I don't have the energy nor the time to tackle that
myself for now unfortunately.
Abdel.