This project would also benefit from providing metadata to the Java Activation Framework. http://java.sun.com/products/javabeans/jaf/
On 4/19/06, Markus Härnvi <[EMAIL PROTECTED]> wrote: > Jörg Schaible wrote: > > That would have been my approach also. I was just not sure, whether we > > should bundle the magic file or try to locate it (this is the interesting > > part and highly system dependent). And a user might have an additional > > magic file in its home - at least this can be located. > > I would wote for bundle, but maybe with an option to search for it. > Windows users don't have it at all, I guess. I'm of the mind that a file type matcher interface should be declared and various implementations should be provided by factories discovered by the Java Service Provider framework [1]. This would allow a basic implementation that creates matchers from an existing unix-like magic file and more complete implementations can be dropped in later by simply adding them to the classpath. The hard part is what that matcher interface expects the data to be in. I can imagine programmers wanting to discover what byte arrays, InputStreams, Readers, Strings, ByteBuffer, and Files contain. Personally, I think Streams and Reader should be dropped as they aren't designed for seek ability and you have to jump through hoops to keep the bytes you read to discover the file type available elsewhere. I like the java.nio.ByteBuffer as the format pass data into the matcher as it's rather easy to get data into it and it can be optimized for File sources. 1. http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
