Oops, I should have added, that I would of course implement
TNiceJSONProtocol (sic) and would be happy to -also- implement
TCompactTextProtocol (the analogue to protobuf CompactText) for all the
languages I address, both alone and in-concert with others.

On Mon, Oct 2, 2017 at 7:40 PM, Chet Murthy <[email protected]> wrote:

> I have sufficient familiarity/mastery of:
>
>   golang, c++, ocaml, perl, java, python
>
> that I can own doing these as a ... "demonstration" of this change.  That
> is, I can do these, as part of the proof that this is a good idea, and
> -before- you agree to accept (of course!)
>
> There's a lotta languages there, so I can't do all of them.  But I think
> it's very reasonable that before you say "yes", you see an important subset
> of languages addressed completely, and of course this means test-coverage
> -too-.
>
> Also, if the first round of languages look "ok", I'm happy to work with
> people who know the rest of the languages well, to get appropriate changes
> for all the other languages.
>
> Uh .... if one of you could let me know if this is sufficient, I'll get
> busy hacking.   Again: not looking for "we'll accept if ...".  rather,
> "we'll seriously consider the change if you do x,y,z".  That's all.
>
> Just tryin' to avoid wasting time (if it can be avoided) is all.
>
> --chet--
>
>
>
>
> On Mon, Oct 2, 2017 at 7:25 PM, Randy Abernethy <[email protected]> wrote:
>
>> It is an interesting idea and I personally see the utility.
>>
>> It is a big ask of course. There are 30 language generators in the
>> Thrift IDL compiler and 28 language libraries.
>>
>> Interested to hear thoughts from other committers. I would be in
>> favor if no one was against (Jens [Jens-G] and James [@jeking3]
>> in particular) and if someone was committed to seeing the thing
>> through with passing tests. I think it would be reasonable to go
>> language by language (doesn't need to be added to everything
>> at once) but would want to see at least several of the key languages
>> updated and an actual protocol provided, otherwise we're just
>> making noise in an already very complex project.
>>
>> My 2 cents
>>
>>
>>
>>
>>
>> On Mon, Oct 2, 2017 at 6:36 PM, Chet Murthy <[email protected]>
>> wrote:
>>
>> > Randy,
>> >
>> > That's it.  Looking at your example, I'd make only one comment:
>> >
>> > I would prefer to emit data-structures that go in both directions --
>> both
>> > fieldid->fieldname, and fieldname->fieldid, to minimize the need for
>> > computation at runtime (in your example, the data fieldid->fieldname was
>> > present, but not the other way around).  For the "nice" protocols, the
>> > fieldname->fieldid mapping is what's needed (at read-time), but heck,
>> > generating them both would be good, I think.
>> >
>> > I take your point about YAML.  There are a small number of nice
>> > human-readable wirelines at this point: YAML, CompactText, JSON.  [as an
>> > Ocaml geek, S-expressoins].  It would be nice to support all of them
>> > "nicely".
>> >
>> > --chet--
>> >
>> > On Mon, Oct 2, 2017 at 5:54 PM, Randy Abernethy <[email protected]> wrote:
>> >
>> > >
>> > > Proposed (cleanest/lowest impact) Fix:
>> > > 1. Modify the compiler to emit a schema for every struct in the types
>> > files
>> > > (struct types include: service method args, structs, exceptions and
>> > unions)
>> > > 2. Modify TProtocol writeStructBegin() and readStructBegin() to
>> accept a
>> > > schema arg
>> > > 3. Modify the compiler to pass the appropriate schema to all calls to
>> > > TProtocol write/readStructBegin() **
>> > >
>> > > Upshot:
>> > > 1. Existing protos would simply ignore the schema arg and new protos
>> > > (text/JSON/YAML/whatever) [de]serialize field names as desired.
>> > > 2. This would be a breaking change, though code could be brought up to
>> > date
>> > > by recompiling IDL and building (without src changes).
>> > > <<<<<
>> > >
>> > > ** I realize that only the read side needs the schema/ordinal mapping
>> but
>> > > something tells me we'll be sorry if we don't maintain the symmetry
>> > >
>> > > Did I miss anything or get anything wrong?
>> > >
>> >
>>
>
>

Reply via email to