Guys, My apologies for the spamming comments -- I tried to submit my comment through JIRA one time and it kept giving me service unavailable. So I resubmitted like 5 times, on the fifth time it finally went through -- but I guess the other comments went through too. I'll try and remove them right away.
Sorry again. Cheers, Chris ______________________________________________ Chris A. Mattmann [EMAIL PROTECTED] Staff Member Modeling and Data Management Systems Section (387) Data Management Systems and Technologies Group _________________________________________________ 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. > -----Original Message----- > From: Doug Cutting (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 05, 2006 8:04 PM > To: [email protected] > Subject: [jira] Commented: (NUTCH-139) Standard metadata property names in > the ParseData metadata > > [ http://issues.apache.org/jira/browse/NUTCH- > 139?page=comments#action_12361922 ] > > Doug Cutting commented on NUTCH-139: > ------------------------------------ > > One more thing. Content length should also not need to be stored in the > metadata as an x-nutch value. The content length is simply the length of > the Content's data. The protocol may have truncated the content, in which > case perhaps we need an x-nutch-truncated-content metadata property or > something, but we should not be overwriting the HTTP "Content-Length" > header, nor should we trust that it reflects the length of the data > actually fetched. > > > > Standard metadata property names in the ParseData metadata > > ---------------------------------------------------------- > > > > Key: NUTCH-139 > > URL: http://issues.apache.org/jira/browse/NUTCH-139 > > Project: Nutch > > Type: Improvement > > Components: fetcher > > Versions: 0.7.1, 0.7, 0.6, 0.7.2-dev, 0.8-dev > > Environment: Power Mac OS X 10.4, Dual Processor G5 2.0 Ghz, 1.5 GB > RAM, although bug is independent of environment > > Reporter: Chris A. Mattmann > > Assignee: Chris A. Mattmann > > Priority: Minor > > Fix For: 0.7.2-dev, 0.8-dev, 0.7.1, 0.7, 0.6 > > Attachments: NUTCH-139.060105.patch, NUTCH-139.Mattmann.patch.txt, > NUTCH-139.jc.review.patch.txt > > > > Currently, people are free to name their string-based properties > anything that they want, such as having names of "Content-type", "content- > TyPe", "CONTENT_TYPE" all having the same meaning. Stefan G. I believe > proposed a solution in which all property names be converted to lower > case, but in essence this really only fixes half the problem right (the > case of identifying that "CONTENT_TYPE" > > and "conTeNT_TyPE" and all the permutations are really the same). What > about > > if I named it "Content Type", or "ContentType"? > > I propose that a way to correct this would be to create a standard set > of named Strings in the ParseData class that the protocol framework and > the parsing framework could use to identify common properties such as > "Content-type", "Creator", "Language", etc. > > The properties would be defined at the top of the ParseData class, > something like: > > public class ParseData{ > > ..... > > public static final String CONTENT_TYPE = "content-type"; > > public static final String CREATOR = "creator"; > > .... > > } > > In this fashion, users could at least know what the name of the standard > properties that they can obtain from the ParseData are, for example by > making a call to ParseData.getMetadata().get(ParseData.CONTENT_TYPE) to > get the content type or a call to > ParseData.getMetadata().set(ParseData.CONTENT_TYPE, "text/xml"); Of > course, this wouldn't preclude users from doing what they are currently > doing, it would just provide a standard method of obtaining some of the > more common, critical metadata without pouring over the code base to > figure out what they are named. > > I'll contribute a patch near the end of the this week, or beg. of next > week that addresses this issue. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Nutch-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nutch-developers
