Being the C++ generated lua interface sluggish (at least twice slower)
I decided that I'll keep working on the old one.
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).
I'll drop ssupport for lua 5.0 (does not have a loadable module
mechanism as 5.1 does)
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.
-- example http log script
require("wireshark")
http_log = Listener.new("http","http.request && http.host ==
www.wireshark.org ")
function http_log.packet(pinfo,tvb,http_data)
print(pinfo.abs_ts,http_data.method,http_data.request_uri)
end
wireshark.open_file("mycap.pcap")
-- end of script
On 9/11/06, LEGO <luis.ontanon@xxxxxxxxx> wrote:
On 9/11/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Both plugins are marked experimental (at least in the Win32 installer) for some time now.
Yes, they are both kinda experimental...
> The LUA scripting support seems to be the way to go, but what's the current state (implementation, documentation, ...). I would like to add some more basic scripting support for the Wireshark GUI like: opening a capture file, applying a display filter, exporting to ...
The current state is that we have a prototype bindding to lua...
I'm on my way to the "good one". Although the current one is
functional it is a little bit messy and it would not allow as-is to
make lua applications that use epan (open a file find this do that and
dump to here... ).
What I'm doing this time is creating a series of C++ classes to wrap
epan objects (proto_tree, proto_item, tvbuff, etc...) and then
generate the lua bindings using either luabind or tolua++ or cpplua.
I want both WS to be extensible in Lua and Lua to be able to use WS as a libary.
> As I don't like the idea of having to support two scripting engines, I would like to mark Mate as deprecated for now, so we can remove it some day, when the Lua support is really stable for a while.
MATE ain't a sripting enguine... Is an educable tool for linking
frames. I been thinking about getting rid of it and changed my mind I
do not think is a good idea of getting rid of it. Me and others still
use it very productivelly.
Luis
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
