[eml-dev] [Bug 2700] New: - Data Manager Library: Sample Calling Application

[bugzilla-daemon@ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2700

           Summary: Data Manager Library: Sample Calling Application
           Product: EML
           Version: 2.0.1
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: datamanager
        AssignedTo: dcosta at lternet.edu
        ReportedBy: dcosta at lternet.edu
         QAContact: eml-dev at ecoinformatics.org


> -----Original Message-----
> From: Matthew Jones [mailto:jones at nceas.ucsb.edu] 
> Sent: Friday, December 15, 2006 12:37 AM
> To: Duane Costa
> Cc: 'Jing Tao'
> Subject: Re: Sample calling application
> 
> Hi Duane and Jing,
> 
> A samle app sounds great.  Comments inline...
> 
> Matt
> 
> Duane Costa wrote:
> > Matt,
> > 
> > Could you add your comments to this discussion about a 
> sample calling 
> > application in the Data Manager Library code? Jing and I both agree 
> > that a sample calling application (as opposed to Junit 
> tests) would be 
> > a useful addition to the distribution, even if it's limited 
> to just the user documentation. However, there are a couple 
> of loose ends Jing and I feel unsure about (see below). After 
> you add your comments, I'll open a Bugzilla entry for this.
> > 
> > Thanks,
> > Duane
> > 
> >> On Wed, 13 Dec 2006, Duane Costa wrote:
> >>
> >>> Date: Wed, 13 Dec 2006 11:32:27 -0700
> >>> From: Duane Costa <dcosta at lternet.edu>
> >>> To: 'Jing Tao' <tao at nceas.ucsb.edu>
> >>> Subject: Sample calling application
> >>>
> >>> Hi Jing,
> >>>
> >>> I think it would be nice to provide a sample calling 
> application in 
> >>> the Data Manager Library source code distribution. It would
> >> just be a
> >>> small program, together with implementations of the
> >> call-back interfaces for database connection pool and Ecogrid end 
> >> point, to demonstrate the different use cases. Do you 
> think this is a 
> >> good idea? If so, there are a few minor things to decide:
> >> It is great idea.
> > 
> > Good! I'll work on the sample program. I'll also add a new 
> Bugzilla bug to document these ideas after Matt adds his comments.
> > 
> >>> * Where to put the source code -- One possible package would be:
> >>>  org.ecoinformatics.datamanager.sample
> This package sounds good to me.
> 
> >>>
> >> I am not sure. But I think since it is sample and it will 
> be good to 
> >> be easy found by the user. So we can still use the package you 
> >> prosposed, but can we put them into a another dir
> >> - sample, which is parallel to src? The dir structure will 
> look like 
> >> sample/org/ecoinformatics/datamanager/sample.
> > 
> > This sounds fine. Maybe we need a separate ant target in 
> build.xml to 
> > compile the sample code, something like 'ant 
> compile-datamanager-sample'.
> Sounds fine.  If its easier to just include the code in src 
> then I might just do that instead of making the parallel 
> hierarchy.  But either way is fine.
> 
> >  
> >>> * How to set properties -- The main program could hard-code the 
> >>> database values as constants, or the main program could 
> read values 
> >>> from the lib/datamanager/datamanager.properties file. The
> >> advantage of
> >>> the first approach is that it keeps the database values
> >> together in the same file with the main program; the 
> second approach 
> >> has the advantage that users can edit 
> datamanager.properties and run 
> >> the sample program without needing to recompile. Which approach do 
> >> you like better?
> >> First, I have a question. How do you plan to run this 
> sample code? It 
> >> will be compiled and distributed too? Or user should compile it by 
> >> himself or through build.xml? Or even just give user an 
> idea how to 
> >> use the library and we don't have plan let user run it? If we just 
> >> want to show user how to use the library and I think it is okay to 
> >> hard code in main program.
> >> If we plan to let user run it (like our test file, it is 
> better put 
> >> those values in the property file.
> > 
> > I don't know which approach is best. Maybe we just want to include 
> > sample code primarily as part of the documentation, without any 
> > expectation that the user will actually compile and execute 
> it. Or maybe we do want the end user to try it out 
> themselves. I think we need Matt's input on this.
> Let's use a properties file.  Hardcoding these values in code 
> is a bad example to set.