Bertrand - The bean approach, as Jukka suggests, would work fine. I just wanted there to be a way to simply turn on or off byte header MIME type detection, add a parser to the configuration, etc, without having to do it via XML.
Properties are often fine. However, having methods for access ensures compile time correctness (i.e. does not suffer from the risk that the programmer mispelled the property name). Also,if we use Properties and can name them anything we want, then we may lose the predictability that could be helpful. For example, in the Metadata issue described elsewhere, if the file name property is called "filename" in one place and "FileName" in another, then we lose the ability to reliably find out the file name from any Metadata instance. If, instead, it is exposed as setFilename() and getFilename(), we're fine. Regards, Keith Bertrand Delacretaz wrote: > > On 10/13/07, Keith R. Bennett <[EMAIL PROTECTED]> wrote: > >> ...I'd like to suggest that we provide an API as well. In general, it >> would be >> easier to use in many cases.... > >> ...What do you think? Should I create a JIRA issue for this?... > > We might want to discuss the design here first, can you give an > example of how your configuration API would work? > > Me, I like to use Properties for configuration whenever possible, as > they are easy to create, using default values and easy to override > individual settings. But there are other ways, of course. > > -Bertrand > > -- View this message in context: http://www.nabble.com/XML-as-Only-Route-to-TikaConfig-tf4616942.html#a13189565 Sent from the Apache Tika - Development mailing list archive at Nabble.com.
