Re: Pluto wishlist

[Peter Cawley <lua@...>]

On Thu, Jan 21, 2010 at 2:34 AM, Rob Hoelz <rob@hoelzro.net> wrote:
> I've been maintainer of Pluto for a while now, and I feel like I should
> move from the role of maintainer to active developer.
>
> For those of you who don't know, Pluto is a heavy-duty persistence
> library for Lua, originally written by Ben Sunshine-Hill.  Here's the
> wiki page for Pluto, as well as my Github page for it:
>
> http://lua-users.org/wiki/PlutoLibrary
> http://github.com/hoelzro/pluto
>
> So, what features would you like to see in Pluto?

I recently needed some fairly heavy duty persistence, and so I looked
at Pluto, but decided that it wasn't suitable for a number of reasons:
    * Pluto uses the private Lua internals, limiting it to PUC-Rio Lua
5.1 and other very similar implementations of Lua. As a result, Pluto
is incompatible with LuaJIT 2, and is probably (at least at the
moment) incompatible with with PUC-Rio Lua 5.2.
    * Pluto persists function prototypes using Lua bytecode, which
kills platform independence, and introduces security concerns -
malicious bytecode can be dangerous.
    * Pluto's writing of binary integers seems to have no regard for
different endianness and different sizes of the underlying types on
different platforms.
    * Pluto's options for [de]persisting userdata are limited. The
literal persistence of userdata is inappropriate, as userdata based on
C/C++ structures may be different sizes or endianness with different
compiler settings and different platforms. This leaves just the fixup
Lua closure option, which is appropriate for some userdata, but not
for others. I would like to be able to have metamethods on userdata,
which operate on a persistence API to write (and later read) arbitrary
binary data and Lua objects.
    * Pluto's serialisation of closures includes the source code
(albeit in binary format, but this is irrelevant here) for each
protoype in the serialised data. This means that if bugs in the source
code are fixed (or similar small changes are made), then only new data
will have the bugs fixed - if the state is loaded from a persisted
file, then old bugs will re-occur, despite being fixed.

For these reasons, I wrote a bespoke persistence library. If you're
interested in the result, then you can read about it at
http://code.google.com/p/corsix-th/wiki/Persistance, and see the
source at http://code.google.com/p/corsix-th/source/browse/trunk/CorsixTH/Src/persist_lua.h
/ http://code.google.com/p/corsix-th/source/browse/trunk/CorsixTH/Src/persist_lua.cpp.
Obviously, I would have liked it if Pluto had been suitable for my
needs, as it would have saved on the work required. Hence the features
I would like to see in Pluto are those which address my above points,
though my needs and design goals are slightly different to Pluto's, so
I appreciate that addressing all of them while maintaining the current
feature set of Pluto is impossible.