Hi Keith,
> 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.
This is the whole point of the interfaces that the Metadata object
implements. The interface classes are meant to aggregate these common string
met keys that are used over and over again in something like Tika.
Then, if desired, you could always write wrapper functions around things
like Metadata.FILENAME such as:
public String getFilename(){ return Metadata.FILENAME;}
If you absolutely had to. Or you could make the class that implements
getFilename() implement the java interface that defines FILENAME. Writing
methods such as the above ;however, are typically only practical in
interfaces that don't change often: otherwise, you'll be adding more get and
set methods as you go along, as opposed to simply adding a key in a table
(which is what the public static final Strings in the java interface classes
are equivalent to.) and then using the addMetadata and getMetadata methods
in the Metadata object.
Cheers,
Chris
> 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
>>
>>
______________________________________________
Chris Mattmann, Ph.D.
[EMAIL PROTECTED]
Cognizant Development Engineer
Early Detection Research Network Project
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
