Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4)

[Andrew Starks <andrew.starks@...>]

On Wed, Oct 7, 2015 at 10:15 AM, Coda Highland <chighland@gmail.com> wrote:
> On Wed, Oct 7, 2015 at 8:06 AM, Andrew Starks <andrew.starks@trms.com> wrote:
>>
>> On Tue, Oct 6, 2015 at 20:46 Sean Conner <sean@conman.org> wrote:
>>>
>>> It was thus said that the Great Andrew Starks once stated:
>>> > On Tue, Oct 6, 2015 at 5:10 PM, Thijs Schreijer
>>> > <thijs@thijsschreijer.nl> wrote:
>>> > >
>>> > > Can of worms... because all other possible formats "would be nice too"
>>> > > as well.
>>> >
>>> > Perhaps a format is needed. Some sort of unholy amalgamation of an
>>> > extension of msgpack and lua's pack/unpack (I think msgpack is little
>>> > endian and lua's format is flexible)? Like LOM is to JSON. That has
>>> > nothing to do with __serialize, but maybe a format specification is
>>> > what is needed to help complete Lua's multi-threaded toolbox.
>>>
>>>   I recommend CBOR.  It's documented (RFC-7049), architectural independent
>>> and extensible (for instance, there are documented extentions for circular
>>> references), easy to encode/decode, and relatively compact.
>>>
>>>   -spc (But I'll admit, I'm a bit biased ... )
>>>
>>>
>>
>> I looked over CBOR. I don't have the chops to criticize it and it looks
>> great to me. :) In my experience:
>>
>> JSON is almost always fine, but if I'm reaching for something that I'm going
>> to use in a Lua <=> Lua scenario, I'd want a better fit. Specifically, mixed
>> tables are something that I wish I could do. I will often do something like
>> `{foo = {some_object = bla}, "foo", bar = {something_else = blab}, "bar"}`,
>> which is useful and not legal JSON. CBOR would meet that requirement, I
>> believe.
>>
>> I don't send closures over the wire. If I want to transfer code, I do so as
>> text and use `load` in the remote lua_state. If 100% Lua data structure is
>> required, it seems like an attainable goal. In my head I've already designed
>> it! But I'm skeptical that something like that is required for most
>> maintainable applications.
>>
>>
>> Most importantly, something needs to be picked. A properly extended CBOR
>> could be canonized on some kind of Lua web site. A library or 10 could be
>> made that supported this format. Various concurrency / Lua-verses could
>> adopt the format. Little Lua nodes could be working together with greater
>> ease, thanks to this and Luaproc and cqueues and Luvit and Love2D and
>> LuaLanes and....
>>
>> I think that it could be a useful addition.
>>
>> -Andrew
>
> I would prefer formalizing on a human-readable format. I think that
> Lua syntax would be the most appropriate choice there, given Lua's
> roots as a way of representing structured data in a human-readable
> format.
>
> /s/ Adam
>

Isn't that what LOM is for?