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.

Reply via email to