EML

-----Original Message-----
From: Matthew Jones [mailto:jones@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@lternet.edu>
To: 'Jing Tao' <tao@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.