[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4)
- From: Coda Highland <chighland@...>
- Date: Wed, 7 Oct 2015 08:15:56 -0700
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
- References:
- Re: [ANN] luaproc 1.0-4, Rena
- Re: [ANN] luaproc 1.0-4, Andrew Starks
- The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Sean Conner
- Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Coda Highland
- RE: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Thijs Schreijer
- Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Coda Highland
- RE: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Thijs Schreijer
- RE: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Rena
- RE: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Thijs Schreijer
- Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Andrew Starks
- Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Sean Conner
- Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4), Andrew Starks