Lars Gullik Bjønnes wrote:
> | No it's not. If the data is passed as a string then we allow the
> | outside world to receive the data, modify it and post it back with
> | no addditional effort to us.
>
> this is the exception (external data), for all internal stuff
> serialization _and_ the mailer stuff are really overkill.
Shrug. There was a simple scheme that worked in 1.3.x where the
frontends stored the inset. Which you didn't like. Now you have a
safe scheme that you think is too complex. Yet I would argue it is
clean and simple and extensible.
Come up with a working alternative and we'll discuss that ;-)
> | I'm imagining a scheme where pybliographer could register as a
> | "replacement citation dialog". Thereafter, clicking on the inset
> | would send the data to Dialogs::show("citation", data, inset) as
> | now, but the data would be posted out through the LyX server (or
> | socket). pybliographer would modify this data and post it back.
>
> And I am not so sure that this is a good idea at all... we shouldn't
> expose external structures like this, and if/when we recieve them
> from external we _must_ do validation anyway...
Sure. We could get that for free if we modified string2params from
static void string2params(std::string const &, InsetBranchParams &);
to return a bool indicating validity...
> in-lyx we do not have to do validation of data since we know that we
> made them in the first place.
Nonsense. We have three frontends now. Anything modified by the
frontend should be regarded as suspect. As suspect as anything coming
from the lyxserver.
> | André argued at the time that this was overkill for what we
> | needed. The read/write methods are what we need.
>
> Which are really just doing just the same ... call it
> poor-man-serialization if you want.
Shrug again.
Incidentally, I believe that boost::serialization does not support
polymorphisism. Which leaves inset->read() dead in the water. Robert
Ramey was suggesting that a second library (that he was not
interested in writing) be written on top of boost::serialization to
support this kind of behaviour.
If I understood things correctly.
--
Angus
