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? > > > > > >
