Re: Pluto updated

[benjamin sunshine-hill <bsunshin@...>]

> Hi, Ben
> 
> Thanks again for great work, I'm going to include Pluto in our project
> framework though it doesn't fit few of our requirements still:

Glad to hear it. :) What's the project, if you don't mind my asking?

> 1. String keys in unpersistables table (you know :) ). This puts a ban on
> plugin architecture. Different set of plugins => different keys in the table
> => wrong reference links.

My current thinking on that is to have a separate set of functions to build the permanents table. You'll be able to hand it top-level namespaces ("coroutine", "string", etc.) and it'll recurse through them and build a permanents table. It'll also build a "linkage map" which you'll serialize along with the persisted data. That linkage map, then, can be used to rebuild the permanents table on the other end by searching through the global environment for the proper keys. I'll eventually make it so that keys that are not found invoke a user-defined function, which can in turn load missing modules and plugins. I'll be working on these functions in the next couple of days, but I haven't yet done enough conceptual work to figure out how difficult it'll be. One thing's for sure: Unlike the current pluto functions, which are designed for the general case, these will be designed for the (more limited) common case. As such, their use will be completely optional.

> 2. Userdata serialization. Serialization via closure requires userdata to
> 'transfer' its state into 'Lua' form. In our case we have complex universe
> of Lua and C++ objects with references between all of them. So serialization
> normally goes on both sides simultaneosly. So during serialization of
> userdata we can (for example) encounter reference to some other C++ object
> that needs to be serialized and this can go very far away from Lua side of
> the project.

I'm not sure that that's a problem at this point. If you have a large area of C data that needs to be serialized, and you want to write your own serialization function, there's no problem with that: just write it out to a string or literally serialized userdata and save it in the fixup closure. On the other end, use the fixup closure to invoke your custom C deserialization functions. Since an arbitrary amount of data may be written, it's the same functionality as if the reader/writer were given directly to the custom serialization/deserialization functions. Does this solution sound adequate?

Thanks,

Ben