libfile and MIME integration

[Christos Zoulas]

On Mar 1,  6:57pm, ian at darwinsys.com ("Ian F. Darwin") wrote:
-- Subject: libfile and MIME integration

| On February 27, 2003 04:00 pm, Christos Zoulas wrote:
| > The next release of file is going to take a bit because I am working
| > on libmagic, a small api that lets people use file(1) functionality
| > programatically.
| 
| I thought this would be coming soon (I was about to suggest it otherwise).
| The GNU project mkhybrid did this and called it libfile; I presume you've 
| looked at their work and are using the same or similar API?

I did not know about that, thanks for pointing it out to me. I will take
a look at it.

| Anyway, my suggestion is on how to do a better job of merging mime 
| types and textual file types, so that only a single data file needs to be 
| maintained. The present scheme with types in "magic" also being present in 
| magic2mime with their MIME correspondents, is not maintainable and violates 
| the "information in one place only" pattern. I thought of something like 
| this:
| 
| 0 long 0x20 {
|         abeco image data
|         image/abeco
| }
| 
| That is, a Struct-like syntax that includes both the standard file response as 
| now, which can be continued etc., as at present, and a single line for the 
| MIME type.
| 
| This has the advantage that you can maintain backwards compatible files
| (either the file string field contains a { or it doesn't), and in libmagic 
| we'll have both file types and mime types.

If we are going to make changes to the syntax, then we should also address
how to handle conflicts and priority of matches/multiple matches. Maybe for
the next version after the library release.

| The API should also be used in Apache mod_file, to get rid of the "code re-use 
| via the copy-and-paste design pattern" that is currently deployed there.
| 

I totally agree,

christos