I submitted a bugzilla [1]. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9940
On Thu, Mar 27, 2014 at 9:01 AM, Nakayama Kenjiro <nakayamakenj...@gmail.com > wrote: > Thanks, > > There are some problems to solve... It's my understanding that there are > following three main points. > > 1. Now there is no Lua dissector yet. And the consensus to include Lua > dissectors is neccessary. > 2. If we will include Lua dissectors, there are two (or more) ways to > consider, a)include the dissector to Wireshark or > b)find/retrieve/install/update/remove plugins from a common repository site. > 3. In every case, we will need some enhancement to load the module, if > Lua dissector is included. > > I will wait for other opinions a little more, and I will submit a request > to Bugzilla. > > Thank you for your advice! > > > PS. I agree to the common repository style, it's great idea. JGroups has > many versions and if we can install by jgroups-$(VERSION), it is very > useful. > > Kenjiro > > > > On Wed, Mar 26, 2014 at 11:55 PM, Hadriel Kaplan < > hadriel.kap...@oracle.com> wrote: > >> >> On Mar 26, 2014, at 1:29 AM, Nakayama Kenjiro <nakayamakenj...@gmail.com> >> wrote: >> >> Recently I wrote new dissector by pure Lua[1] and I am thinking about >> submitting a request to include the dissector to Wireshark. >> But as far as I checked upstream, there are no pure Lua dissector yet. >> >> >> Right, none yet. >> >> The challenge I think is that most of the core developers don't know Lua >> nearly as well as C, so it would be hard for them to fix any bugs, or >> enhance it in the future to support some new version of the protocol being >> dissected (JGroups in your case). >> >> But as long as they're ok with the idea, I think it would be great to >> have such. It might even bring in more protocols, because it might be >> easier for some people to write one in Lua than deal with trying to figure >> out how to compile the source, or learn C if they don't know it already. >> >> An alternative approach is to do what many other apps do: have a >> mechanism to find/retrieve/install/update/remove third-party plugins from a >> common repository site. That way the plugins themselves aren't part of the >> application package and aren't officially maintained by the core >> application developers, but instead are maintained by the third-parties (or >> not, and they die off, which isn't a bad thing either). Many good text >> editors/IDEs do that, for example, as do browsers, etc. Some even do it >> with the ability to pull plugins from github directly, instead of storing >> the plugins in their own site. >> >> >> And I don't know where shoudld I put the code in and how to modify >> Makefiles. >> >> >> Right now two Lua files are included with Wireshark: init.lua, and >> console.lua. Both are in epan/wslua and copied in the global configuration >> directory for installs/packages. (well, init.lua is actually generated from >> a perl script using template-init.lua) If you grep the code for >> "console.lua" you'll see the various files that move it around. >> >> But the global configuration directory isn't the right place really for >> Lua dissectors, nor is epan/wslua for the source repository. They should >> probably be put into the plugins/ source directory, and be installed into >> the global plugins directory. >> >> But we can work out those details if/when there's consensus to include >> Lua dissectors. For example we might wan to change the loading code a bit >> for plugins, to have it check if a file of the same name exists in the >> user's personal plugins directory, and if so then to load that one instead >> of the one in the global plugins dir. Or use a filename version schema and >> load the newest one. >> >> >> So my question is >> Is there any guideline to include pure Lua dissector? If no guideline >> yet, why don't we make it? >> >> This is my personal opinion, now Lua became good for writing a new >> dissector and samples like /test/lua/dissector.lua is really great. New >> dissector written in Lua request will increase in the future. >> >> [1] https://github.com/nak3/jgroups-wireshark-dissector >> >> Thanks, >> >> Kenjiro >> >> -- >> Kenjiro NAKAYAMA <nakayamakenj...@gmail.com> >> GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9 >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe<wireshark-dev-requ...@wireshark.org?subject=unsubscribe> >> >> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > > -- > Kenjiro NAKAYAMA <nakayamakenj...@gmail.com> > GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9 > -- Kenjiro NAKAYAMA <nakayamakenj...@gmail.com> GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
