This is because wssdl is still within the boundaries of the lua grammar: the file you provide is still lua, so you have to abide by its rule.
I experimented with a key/value approach on the syntax itself (something like `{ src_port = u16 }` or `{ src_port = 16 }`), which was nicer, but the problem was that, in lua, table literals are unordered. The current approach uses the method syntax (`a:b()`) as a nice workaround, but this mandates the use of parenthesis after the type and other specifiers. This is fine though since a lot of the provided types are parameterized (e.g. `bytes(n)` which takes a number of octets)
Great idea! I have always felt that the Wireshark Lua bindings are not ready-to-use enough. They feel like the ugly stepchild of Wireshark.
In the last dissector I wrote, which was about 1000 lines of Lua, I built a very limited structure definition parser, not completely unlike wssdl. I did it to cut down on the repetitive code needed parse the structures: Typically I parse every field twice: Once to add it to the dissection tree and once to get its value as a Lua-held variable.
I'll definitely be using wssdl in my next dissector!
v3 means that if it's used (even over a network) by somebody, they can request the code, versus GPLv2 (Wireshark license), which says if you distribute binaries of Wireshark or software based on it, you must provide the source. The difference is that you could theoretically provide a web interface to a GPLv2 project and not need to supply the source, but if you provide such an interface to GPLv3 software, you could receive a request for the code.
EDIT: I'm not entirely correct There are provisions for the network situation ("ASP (application service provider) loophole") I described, but I looks like it's not necessarily the default mode. See [0][1].
The GNU GPL v3 does not contain such a provision. However, a different license, the GNU AGPL v3, does. Your post is entirely incorrect regarding the GPLv3.
As Wikipedia notes, some drafts of the GPLv3 contained such a provision, but this did not make it into the final version.
It's considerably more flexible, much more elegant, and (in Erlang) battle-tested.
I wrote an Erlang-inspired version of bitstrings for OCaml: https://people.redhat.com/~rjones/bitstring/html/Bitstring.h...