Hey Michael, The archives to the mailing lists are linked here:
http://mail-archives.apache.org/mod_mbox/ You will also see the ones that we had for the OODT project as we were in incubation. Hope this helps, Paul Ramirez On May 23, 2011, at 4:14 PM, Starch, Michael D (388L) wrote: > Chris, > > Is there some sort of coding standards document that I should be abiding by, > or does oodt just follow standard java "best practices"? This is the kind of > information that seems like it would be easier for me to look up rather than > ask on the developer list. > > Finally, how can I access the archived dev-list mailings? > > Thanks, > > Michael > > > On May 19, 2011, at 11:06 PM, Mattmann, Chris A (388J) wrote: > >> Hi Michael, >> >> I'd be happy to reply below, but yes I'd suggest initially CC'ing >> [email protected]. Giving this information is great, but I prefer the >> community to benefit from these types of discussions (and it means that I or >> you or Albert or Cecilia can point others to this question if it is asked >> again rather than typing the same answer again or fwd'ing something >> private). Also no worries about researching it -- you can ask questions on >> that list -- researched or not. We welcome feedback from the community. >> >> Answers inline below: >> >> On May 19, 2011, at 2:44 PM, Starch, Michael D (388L) wrote: >> >>> Chris, >>> >>> In order to create tables in the new database architecture that Brian >>> Foster set up for use, we need the ability to specify some information >>> beyond that which is stored in elements.xml. We wish to store this >>> information as part of PCS, rather than continually haggling back and forth >>> with our DBA in order to get this set in an ad-hoc manner. >>> >>> The data we need to store is: >>> >>> -Is it a vector type? >>> -Data-type >>> -Max data size >>> and potentially a few more items. >> >> Gotcha. >> >>> >>> As it stands now, Brian has used the DCElement tag in elements.xml file in >>> order to store some of this information but not all of it. Thus it seems >>> natural that the rest of this information gets stored along side it. >>> >>> There seem to be three ways to accomplish this: >>> >>> 1. Add more information to the DCElement tag, >>> 2. Add additional tags to the element file containing this information >>> 3. Create a sperate file to store this information (Not part of PCS) >> >> I've got a 4th option. >> >> 4. Write a new ValidationLayer implementation, that extends >> XMLValidationLayer, but adds your desired information to elements.xml. For >> that extra information, I'd favor your proposed option #2 -- I think it's >> cleaner. >> >>> >>> As head of oodt, we were looking for you input as to which option to >>> choose, or if you wish this question to be brought to [email protected], >>> where can I research this information before asking the question on that >>> list? >>> >>> Below is a brief analysis of each option, from our perspective. >>> >>> Thanks, >>> >>> Michael Starch >>> >>> 1. Add more information to the DCElements tag. >>> -I believe Brain said this tag was unused, so he "borrowed" it to suit >>> this purpose. >>> -Adding more information to the tag would "hijack" this tag to a >>> further extent. >>> -The changes could be made locally to our ColumnBasedDataSourceCatalog >>> in the manner Brian already used. >>> -If the DCElement is used ouside of the new use Brian invented, this >>> change could affect the intended (original) use >> >> I don't like this one (nor do I think others will) since it hijacks >> dcElement (which is supposed to be a mapping to a Dublin Core element name, >> rather than used for other information). >> >>> >>> 2. Add more tags to elements.xml >>> -Most elegant solution, as each data field has a tag specified to hold >>> exactly it >>> -No need to use tags which were originally intended for some other >>> purpose >>> -It is an architectural change, changing the format of the elements.xml >>> file >>> -Must be done carefully to prevent us from deviating from apache-oodt >>> when it is not necessary to do so. >> >> +1 for this option. >> >>> >>> 3. A separate file >>> -Creates data/configuration duplication, as some of these fields must >>> stay (in some form) in elements.xml >>> -Separates similar pieces of data >>> -Doesn't alter PCS as it exists now >> >> This is fine too, but I prefer #2. >> >>> >>> We favor number 1 or number 2 as it keeps similar data together, and feels >>> like it is the most logical place to store this information. >>> >>> I personally favor number 2, as it does not use tags for unintended >>> purposes, but I do not wish to make a change that affects our compatibility >>> with apache code. Hence your input. >>> >> >> +1 to your preference. I think the way to accomplish it is to write a >> YourExtendedValidationLayer extends XMLValidationLayer and that provides a >> customized: >> 1. YourElementClass extends Element >> - provides extra props (getters+setters) that you want to leverage >> 2. implementations of the SerDe for your specialized elements.xml that >> includes those extra tags >> 3. provides the ability to access this ValidationLayer information and >> Element information in ColumnBasedDataSourceCatalog. >> >> BTW, I think it would be great to bake up patches for Apache OODT for what >> you are working on, including ColumnBasedDataSourceCatalog (already there >> but in a branch, would be nice to forward port to trunk, and your proposed >> ValidationLayer and Element extensions). Thoughts? Do you have the time? I >> think the community at Apache would sincerely appreciate the effort. >> >> Cheers, >> Chris >> >> P.S. Would you be OK with me forwarding this thread to [email protected]? I think >> there's some good info here that I'd hate to be lost in the ether... >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Chris Mattmann, Ph.D. >> Senior Computer Scientist >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> Office: 171-266B, Mailstop: 171-246 >> Email: [email protected] >> WWW: http://sunset.usc.edu/~mattmann/ >> Phone: +1 (818) 354-8810 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Adjunct Assistant Professor, Computer Science Department >> University of Southern California, Los Angeles, CA 90089 USA >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >
