Re^3: Parsing of serialized data

If you have put in the legwork on a good, generalized “HTTP parsing” solution ... that is a better mousetrap ... and that can be built to the standard-of-quality of CPAN such that you are actually willing and able to do it, then of course there will be great interest in what you have done.

If you really can “Name That Tune™ in two days,” then by all means, go for it. What we all will expect is a thoroughly implemented and self-testing module, with at-least adequate documentation and generalized applicability, such that thousands of other people can “drop in” your solution to their applications and actually save time thereby.

Naturally, it will behoove you to thoroughly understand what is already out there, and why your work is distinctive and different. It is quite frequent, and quite embarrassing, to discover that you have poured heart-and-soul into an effort that did not need to be done at all.

Nevertheless: If you’ve got a better mousetrap, heh, we are certainly not running short of mice. There are many thousands of CPAN modules, and always room for one more. I say these things to encourage you to get busy. The Hall of CPAN Contributors (oddly, I myself am not one ...) is a hallowed hall, indeed.

Replies are listed 'Best First'.
Re^4: Parsing of serialized data by andal (Hermit) on Nov 02, 2010 at 09:42 UTC
Aha, now I understand what generalized means :) Obviously, this is all true. And it might be the reason why some modules don't end up in CPAN. On the other hand, there are thousands of modules there. But the modules that provide the interface I've described are the minority. So the generalization process shouldn't be the explanation for this situation. Just to be clear. I'm not trying to find an excuse for not attempting to share some of my work. I'm trying to understand why nobody had shared similar work already. There are lots of modules that handle HTTP by reading sockets, why there are almost no modules that just parse HTTP without handling sockets? :) So far, my guess is, such modules are considered to be too complex for "drop in" usage, so nobody feels like going that way. Effectively, this can be called "design flaw". Another example. XML parsers. The perl module XML::Parser uses the underlying expat library. The library itself uses the "Parser" approach. Ie, it processes data as the user provides it. Nevertheless, the XML::Parser does not provide the same interface. Instead it provides the front-end that does the reading for the user. (Well, there's XML::Parser::ExpatNB module that provides the "pure" expat interface). The point is, the creator of XML::Parser wrapper also considered the approach taken by expat author to be too complex. No need to mention, that the most popular way to parse XML is to let the parser create the object and then search in that object for the nodes that are interesting. This is what most of modern parsers offer. So, it seems that even though the "divide and conquer" approach to data parsing promises lots of flexibility, in reality it is not used because majority of developers favor simpler interfaces over the flexibility.	[reply]

Replies are listed 'Best First'.

Re^4: Parsing of serialized data
by andal (Hermit) on Nov 02, 2010 at 09:42 UTC

Aha, now I understand what generalized means :)

Obviously, this is all true. And it might be the reason why some modules don't end up in CPAN. On the other hand, there are thousands of modules there. But the modules that provide the interface I've described are the minority. So the generalization process shouldn't be the explanation for this situation.

Just to be clear. I'm not trying to find an excuse for not attempting to share some of my work. I'm trying to understand why nobody had shared similar work already. There are lots of modules that handle HTTP by reading sockets, why there are almost no modules that just parse HTTP without handling sockets? :) So far, my guess is, such modules are considered to be too complex for "drop in" usage, so nobody feels like going that way. Effectively, this can be called "design flaw".

Another example. XML parsers. The perl module XML::Parser uses the underlying expat library. The library itself uses the "Parser" approach. Ie, it processes data as the user provides it. Nevertheless, the XML::Parser does not provide the same interface. Instead it provides the front-end that does the reading for the user. (Well, there's XML::Parser::ExpatNB module that provides the "pure" expat interface). The point is, the creator of XML::Parser wrapper also considered the approach taken by expat author to be too complex. No need to mention, that the most popular way to parse XML is to let the parser create the object and then search in that object for the nodes that are interesting. This is what most of modern parsers offer.

So, it seems that even though the "divide and conquer" approach to data parsing promises lots of flexibility, in reality it is not used because majority of developers favor simpler interfaces over the flexibility.

[reply]