>Considering the cost of the system and short time we have
>to implement the software, we would like to quickly become
>functional in the software that we will eventually be using.

I'm glad you're keen to quickly become functional! Between RCF,
the experiments and the Grand Challenge we are setting up an
evaluation of Objectivity and assessment of alternatives for
an event store. I would like Herb to play an important role
in the evaluation. 

What really drives my interest in Objectivity is how small the
cost is in FTE-year units, compared to the coding investment we'd
have to make ourselves without it, when in terms of both time and
money we have few FTE-years to work with.

>We heard at the meeting that there are five development licenses
>purchased at a price of $62,000.  We are interested in using
>one of these to explore Objectivity.

As I said I'll point you to Objectivity as soon as Martin tells us
it is set up. Incidentally the cost of those licenses will be credited
against a bulk purchase later, if the purchase is reasonably soon.

>Would we replace STIC with the DDL processor?  ------------------
>If so, how much will the necessary development licenses
>(one for every machine doing STAR table development)
>cost? -----------------------------------------------------------

The bulk purchase of circa $400k will provide developer licenses for
all active RHIC physicists to define their own schema, ie. the
licenses purchased will all be developer licenses.

>Will typical STAF users be forced to translate their current idl
>files into Objectivity DDL code?  -------------------------------
>Do they have time to do this?    -------------------------------

I expect the initial Objectivity implementation to be thin object
wrappers around existing tables, with a very simple and perhaps
automated (if it seems worthwhile) conversion from existing IDL files.

>Would we replace calls to Greiman's DSL package with calls to the
>database?  ------------------------------------------------------
>If so, much sys branch code will have to be re-written:
>        1 call  in AMI
>       20 calls in TNT
>       23 calls in TOP
>       35 calls in DUI
>       42 calls in DSU
>       47 calls in TBR
>       58 calls in DIO
>      111 calls in TDM
>      ---
>      337 calls
>There is much setup and interpretation code surrounding each
>call, so that the amount of code change would be 3-10 times 337
>lines.  Would adopting Objectivity force us to rewrite these
>3-10 times 337 (1000-3000) lines of code?  -------------------
>Do we have time to do this?    -------------------------------

Do we have time to rewrite 3000 lines of code?? We better, since
the number of new lines we have to write is a helluva lot more than
that. I defer to Craig to actually answer the question.

>One popular theme is "computing on small scale systems 
>(eg, NT machines)".  Do we want to restrict STAR 
>computing to computers with a high-speed connection to a
>central database (i.e, no computing on airplanes or typical
>homes)? --------------------------------------------------------

No, we certainly don't want to impose such a restriction, and
such a restriction isn't inherent in going with Objectivity.
Direct connection to the central database provides capabilities
of great interest to us but our design must allow for standalone
work also.

>Will the cost of direct access devices for tens of
>terabytes will be a major factor in the cost of our
>computing? -----------------------------------------------------
>If so, we might well be interested in on-the-fly data compression.
>If we adopt Objectivity, will we have eliminated on-the-fly data 
>compression as an option?  -------------------------------------

I've been thinking of wrapping compressed raw DAQ events as
Objectivity objects. You can always just turn a byte bucket that
happens to be compressed data into an object. Media cost will be
a major factor so compression will be important, though whether
beyond the raw data stage compression algorithms will be successful
and important, rather than just designing compact data representations,
isn't clear to me right now.

>Besides the large cost of Objectivity itself, there is
>the question of having a database manager working for us.  
>Are we prepared to dedicate some fraction of an FTE to 
>this?  -----------------------------------------------------------
>(Note: such an FTE would seem to be more than usually liable
>to migration from physics to the commercial world).
>======================================================================

I was very glad to see in the RCF reviewers' comments the statement
that we should not make a decision on Objectivity on the basis of
cost: if it meets our needs, buy it, because implementing what it
covers ourselves would cost far more in manpower. Of course I agree
with this view completely. Whatever database management manpower we
need is going to be substantially less than what would be needed to
support, maintain and document a home-grown solution (so I maintain).
To turn your commercial world argument around, it is a lot harder to
hire people to work with in-house, commercially irrelevant,
possibly technologically antiquated software. 

The next two are at this point my answers, not Objectivity's:

>1.  Your WWW page  
>         http://www.objectivity.com/Products/platform.html
>    says "For example, data created by applications on a 32-bit
>    NT platform can be read, updated or deleted by applications 
>    on a 64-bit UNIX platform."   Is this true for object _methods_
>    as well as data?

It must be true for methods as well as data. Storing methods as
well as data -- complete objects -- is what Objy is all about,
and support of a platform by Objy has to mean full inter-platform
ODBMS with other supported platforms, 32-bit, 64-bit or whatever.

>2.  In Chapter 2, "Product Family Overview" of "Objectivity, Tech-
>    nical Overview", in the paragraph labeled "Advanced schema
>    evolution capabilities", you say "Supported operations include
>    renaming and deleting a class, adding, deleting ..., many
>    others".  Why is revision of an object method (say, in case
>    of a found bug) not in this list?  This is one of the things 
>    that typical users would need.

My understanding is that maintaining revisions of methods is
supported.

On both these questions, we should look carefully at the full Objy
doc before going to Objy with the questions. I am trying to get
1-2 hardcopies from Martin. BaBar has prepared PDF versions online
of the full doc which I hope to be able to make available.

>After listening to the talks that you and Craig gave about
>Objectivity, and after reading the documentation from 
>Objectivity's WWW site, I would conclude that its major
>benefit to STAF would be relationship navigation among the 
>objects.

No, I'd say that relationship navigation is one aspect of a much
larger benefit stated broadly as providing the capability to
largely automate the storage/retrieval implementation and 
management of our data, greatly ease the bookkeeping job of
managing it all, at all the various levels of the data processing
chain, and manage (through the HPSS interface) interaction with
the mass store. Objectivity doesn't do everything for us, but it
does a good chunk, leaving us to fill in the cracks and not build
the edifice.

>Lanny and I and the EbyE working group have discussed
>handling relationship navigation between data files (eg, 
>"This DST has only electrons.  Where is the original data 
>file?") by embedding a list of progenitor files into each xdf
>file, and then periodically extracting this information
>out of the mass storage system (eg, using a UNIX find) 
>into the Oracle relational database for interactive access.

A simple statement of an extremely large and complex problem
and an oversimplied statement of a -- certainly possible, with
enough effort, but wise? -- homegrown solution.

>What are some of the specific problems that RHIC has
>that Objectivity might be able to help solve?

See above.

You have asked good questions, some frequently heard, all I think
of wider interest; please tell me whether you'd mind if I posted
this widely (eg. to the SOFI list).

  - Torre