lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, Oct 7, 2015 at 8:06 AM, Andrew Starks <> wrote:
> On Tue, Oct 6, 2015 at 20:46 Sean Conner <> wrote:
>> It was thus said that the Great Andrew Starks once stated:
>> > On Tue, Oct 6, 2015 at 5:10 PM, Thijs Schreijer
>> > <> 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

/s/ Adam