[Sébastien Tandel <sebastien@xxxxxxxxx>]

Hi Luis,

I'm happy to see you're enthusiast! :)

On Sun, May 31, 2009 at 22:01, Luis EG Ontanon <luis@xxxxxxxxxxx> wrote:

I made the Lua bindings an application of the C API, not a simple
export. (e.g. proto_item and proto_tree are combined instead of dealt
individually, objects are managed in their scope so that deleted
objects are not accessed by Lua).

As a rule of thumb, I'm trying to follow the C API but the main idea is of course to simplify whenever possible and write less code.

That's why I'm not against following some parts of the LUA API. My main goal is to ease development for others people.

The reasons why I avoided just mapping the C API were many but all
focused on a single point: to make sure that a bug in lua code was
hanlded by lua's handler, not by a crash.

For sure, that's something I have to work on :)

Maybe I did not insist sufficiently on it but it's the *first step* to have a python binding with wireshark. There are a lot of things to do , features to add,  bugs to fix, etc...

Another drive was simplyfing some wireshark concepts to make coding in
lua leaner, if it will take me the same number of lines to write code
in lua than it takes me to write it in C why not just write it in C.

That's something I want to avoid too. And it's already rather concise, maybe not as concise as LUA is right now? maybe.

I had no python experience at the time and I had heard many good
things of it... Having dealt way too much (for my taste) with python
latelly now IMHO the only think which python does better than perl is
well indented code (the thing cannot even help you find a typo in the
name of a variable, closures are cumbersome, global variable usage is
painful at very least... as for java I do not understand why so many
people like it).

OK, perl lover ... I was working with perl some years ago and I'm really happy to be able to avoid its use today!

BUT my point is that if there were a binding in perl, it would be a good thing for wireshark because there are a lot of people using it. I just won't do it myself. In the same way, I do think that python is a good thing for wireshark too. At the end of the day, just a few people knows LUA. Even being in Brazil, country of origin of LUA, working for one of the largest brazilian IT company, people knows LUA because it's brazilian but nobody can (or want to) develop with it.

After all, having a binding is not only for me or for other core people. Having a binding is to ease wirehark extension development for the rest of the community (mainly sysadmin and net guys). If we use an unknown language, like let's say D, it is of little interest because just an elite knows it. (and probably this elite won't even take a look at wireshark). I know that at the company I'm working in, sysadmin and net guys are using a way lot more python than perl, do not even think they could one day extend wireshark in C and as I already said LUA is just known by its name because of its origin. Therefore, what would you choose?

Regards,

Sebastien Tandel

 

On Sun, May 31, 2009 at 10:41 PM, Sébastien Tandel <sebastien@xxxxxxxxx> wrote:
> Hi Stig,
>
> First, I have to admit that I'm not really aware of the details of the
> defined LUA API. But as a rule of thumb, I tried to be close as possible to
> what exists in the C API (not LUA).
> Here is an informal description of what rules I tried to follow to create
> this API :
> 1) create objects as close as possible to the ones known in libwireshark
> There are three "obvious" objects until now : Dissector, Tree, TVB.
> 2) method name of each object as close as possible as the ones defined in
> libwireshark. I however modify the name because as C is not object, most of
> the time, a function includes in its name the conceptual "object" name
> related to it. This way, it avoids redundance in python API. For example :
> "proto_tree_add_item" is one method of the "tree" object in the C API. in
> the python API, the Tree class defines a "add_item" method. With the same
> idea for "tvb_get_ntohl", the method is defined in the TVB class with the
> name "get_ntohl".
> 3) formal parameters of functions :
>   a) first parameter is in general the "C object" and it does not make any
> sense to include it for the method defined in a python object. (in fact, in
> python it appears in the definition and "disappears" when called)
>   b) it might happen that some other parameters are always defined in the
> formal parameters of the C API but are not manipulated by the user and might
> be included automatically by the python API. For these ones, they also
> disappear from the formal parameters list of the python API.
>   c) if the parameter takes most of the time one value but sometimes can
> take another value, it is defined as an optional parameter.
>   d) if the parameter is totally or partially managed by the python API, it
> is defined as an optional parameter.
>   a good example is Tree.add_item(self, field, offset=0, length=-1,
> little_endian=False, adv=True)
>   the C API counterpart is : proto_tree_add_item(proto_tree, hfindex, tvb,
> start, length, little_endian)
>     - As of rule a), proto_tree is in fact the Tree object => disappear from
> the formal parameter list
>     - As of rule b), tvb is not directly manipulated by the user and
> therefore disappear from the formal parameter list
>     - As of rule c), little_endian has two possible value False or True. It
> becomes an optional parameter with the default value set to False.
>     - As of rule d), "offset" is totally managed by the API with the help of
> the last *added* parameter which indicates whether offset should be
> incremented or not. This last parameter is itself an optional parameter with
> a value of True ("offset" is incremented by "length"). Though, offset is
> totally managed by the python API, it is possible to increment manually the
> offset.
>
> There is already two notable exceptions to what I described here above.
> There exists two others objects (register_info and Subtrees). It is likely
> that in the future this list of objects will increase because they've
> initially have been created because of a "ctypes" (python module)
> limitation.
> At the end, they almost serve only as a special dictionary of elements.
> For these objects, I used a so interesting feature of python, definition of
> dynamic attributes.You have a first step in which you add items in this
> "dictionary" (hf_register_info fields and trees). When you have to refer to
> one of these while dissecting, you can refer to them as if they were
> attributes of the related object.
> For example, let's say "hf" is a register_info object, you can add something
> to it by doing :
>   hf.add("Imaginary Protocol Length", "imaginary.length", FT_UINT8)   => Not
> that you have a lot of optional parameters in here!
> and you can refer to this field while dissecting with
>   hf.imaginary_length
> the name of the attribute is the second parameter passed with every '.'
> changed to '_'
>
>
> That's all for now .. I'll add this mail to the wiki documentation.
> Of course, I'll enjoy any comments (from you or anyone else) to improve the
> python API whatever it be following the LUA API or not. :)
>
>
> Regards,
> Sebastien Tandel
>
> 2009/5/31 Stig Bjørlykke <stig.bjorlykke@xxxxxxxxx>
>>
>> Hi,
>>
>> Do you use the same naming scheme in the Python bindings as we use in
>> Lua?
>> I think we should have the same names for equal functionality in both
>> Python and Lua.
>>
>>
>> --
>> Stig Bjørlykke
>>
>>
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe