LEGO wrote:
Being the C++ generated lua interface sluggish (at least twice slower)
I decided that I'll keep working on the old one.
Sounds reasonable.
Here's what I'll do:
For now I checked in a slightly modified version into epan/ which by
now only *nix build uses (that's why I haven't deleted the plugin
yet).
Having two different ways to load lua might be confusing and difficult
to document. Please finish the changes :-)
I'll drop ssupport for lua 5.0 (does not have a loadable module
mechanism as 5.1 does)
No problem.
I'll be working soon in a mechanism to be able to load and use
libwireshark.dll from lua (not just to extend ws with lua) so that
applicaations that use libwireshark can be actually written in lua.
I'll need help to understand how ws loads, opens files and captures
and how the() interface to lua should be.
Working with libwireshark directly should have a good reason that I
can't see.
The result in the long run might be ending up with "tiny" ws-like
applications that are not combinable with each other.
Keeping lua scripts under the "hood" of ws makes it much more likely
that extensions build by third parties are combinable.
I still don't see the goal you're trying to achieve with the lua binding
here.
Having a way to "remote control" Wireshark with lua - we could have a
"Tools" menu item where you can execute lua scripts - might be very helpful.
Regards, ULFL
