Skip Menu |

This queue is for tickets about the Data-FormValidator CPAN distribution.

Maintainer(s)' notes

This is the bug queue for Data::FormValidator.

Report information
The Basics
Id: 54875
Status: open
Priority: 0/
Queue: Data-FormValidator

People
Owner: Nobody in particular
Requestors: REHSACK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Favour File::LibMagic over File::MMagic
Hi Mark, File::LibMagic has a much better file type guess database than File::MMagic. Maybe you should favour this module over the slow, incomplete and not actively maintained File::MMagic. Best regards, Jens
Subject: Re: [rt.cpan.org #54875] Favour File::LibMagic over File::MMagic
Date: Mon, 22 Feb 2010 10:21:31 -0500
To: bug-Data-FormValidator [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Show quoted text
> File::LibMagic has a much better file type guess database than > File::MMagic. Maybe you should favour this module over the slow, > incomplete and not actively maintained File::MMagic.
Jens, I agree File::MMagic is not ideal. I will consider the options further. One goal I have for the project is to work without any XS dependencies, or other complicated external dependencies. The "Related Modules" section of File::LibMagic is helpful. I will consider the options further. One option I will look at is to make this part "pluggable", so it's easy to replace the default file/magic detection if you don't like the built-in one. Mark
Subject: Re: [rt.cpan.org #54875] Favour File::LibMagic over File::MMagic
Date: Wed, 24 Feb 2010 16:04:33 +0000
To: bug-Data-FormValidator [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] web.de>
On 02/22/10 15:22, mark@summersault.com via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=54875> >
>> File::LibMagic has a much better file type guess database than >> File::MMagic. Maybe you should favour this module over the slow, >> incomplete and not actively maintained File::MMagic.
> > Jens, > > I agree File::MMagic is not ideal. I will consider the options further. > > One goal I have for the project is to work without any XS > dependencies, or other complicated external dependencies.
The biggest problem there (from my point of view) is, that all available file/magic detection libraries/utilities/modules have a different opinion how to call/name specific type. Many people (or packaging systems) are able to support XS very well, so having the option to work with or without XS depending on user/packager choice would be great. Show quoted text
> The "Related Modules" section of File::LibMagic is helpful. I will > consider the options further.
I've checked a lot of them in a customer project. File::LibMagic is fast, reliable and I know the author of the file(1) and libmagic(3) (he's member of The NetBSD Foundation), which let's me give him direct feedback on "internal" channels about incompatibilities etc. Show quoted text
> One option I will look at is to make this part "pluggable", so it's > easy to replace the default file/magic detection if you don't like the > built-in one.
Great \o/ | / \ Best regards, Jens
Subject: Re: [rt.cpan.org #54875] Favour File::LibMagic over File::MMagic
Date: Wed, 24 Feb 2010 11:59:05 -0500
To: bug-Data-FormValidator [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Show quoted text
> The biggest problem there (from my point of view) is, that all available > file/magic detection libraries/utilities/modules have a different opinion > how to call/name specific type. > Many people (or packaging systems) are able to support XS very well, so > having the option to work with or without XS depending on user/packager > choice would be great.
I don't mind supporting a good XS-based solution, as long as there is a non-XS option. Show quoted text
> I've checked a lot of them in a customer project. File::LibMagic is fast, > reliable and I know the author of the file(1) and libmagic(3) (he's member > of The NetBSD Foundation), which let's me give him direct feedback on > "internal" channels about incompatibilities etc.
Good to know. Further feedback and patch or API proposals are welcome. Mark