Re: Which packet sniffing module should I choose?

The one time I can think of where I really had to research a bunch of modules to find something I wanted to use in production was finding something to use with XML. I downloaded and tested a whole bunch of modules. I poured over their documentation. I tried using each one in a scaled down prototype of what I would eventually try to do with them. And then I decided.

My basis was everything. How easy was it to use or learn. How complete it was feature-wise (YAGNI-be-damned, I didn't want to wait until I needed it before asking the module author to implement it). How useful it would be in not just this program, but other programs in the same field (learn one technology, reuse that learning in many places). And, how perlish it was. Some of the modules were thin wrappers around underlying C code with the barest of syntactical sugar to at least make it conform to perl (converting char*'s and int's to plain scalars, for example). Others not only believed in TIMTOWTDI, but were, by themselves, MTOWTDI.

I obviously picked XML::Twig. Which of yours you should pick? I don't know. But maybe the above will help you figure out how to pick one.

Comment on Re: Which packet sniffing module should I choose?

Replies are listed 'Best First'.
Re^2: Which packet sniffing module should I choose? by djp (Hermit) on Oct 02, 2006 at 04:38 UTC
I went through much the same exercise a year or so ago, and also picked XML::Twig. But I spent a lot of time on the research, there was no obvious place to go to find out even what was most popular, let alone what was the 'best'. Why do you say you 'obviously' picked XML::Twig? More recently, I had to do some XML stuff and this time picked XML::Smart, which suited the particular task better. But again I had to do my own research.	[reply]
Re^3: Which packet sniffing module should I choose? by Tanktalus (Canon) on Oct 02, 2006 at 13:37 UTC
If you read my basis for selection, you'll notice that one of the basis was having a single solution be MTOWTDI. XML::Twig is the only module that I know of that has more than one approach to XML. You can deal with each twig during processing (before or after or both) - great for transformations. Or you can load the whole thing into memory and use xpath-like expressions to find your data. I usually do the latter, though I've used the former from time to time. It appears, from a very cursory glance, that XML::Smart is not necessarily a lot different from XML::Simple. XML::Smart may be able to handle more cases, and seems to have more syntactical sugar, but it, too, seems to take XML and simplify it down to common perl structures. Which means it can be great for things like serialising data for your own use. But may not be so great for fulfilling certain DTDs. XML::Twig seems to have two very important features that make it the only choice for me. In order of priority for me and my use (which may not apply to you in your situation, that's why there really are many ways to do things), they are: a) XML::Twig keeps everything in its original context. This can be important in fulfilling those DTDs. What this means is that if I have two pieces of XML such as: `<foo> <bar>blah</bar> </foo>` [download] and `<foo bar="blah" />` [download] that XML::Twig handles these differently. However, XML::Simple does not. (You can choose the output of XML::Simple to be one or the other, but I'm not sure how to get it to do both - and to do that depending on the original input.) I suspect that XML::Smart does not do this either. And, b) of the modules that do (a), it does so in the simplest, most perlish way. The modules that do (a) are generally the low-level ones that wrap around the DOM or whatever parsing mechanism they use at a very direct level. By no means is XML::Twig "simple" - but of this group, it is easily the winner. Does that mean it's always the best module to use? Not necessarily. But it has been for me.	[reply] [d/l] [select]