<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Richard,<br>
<br>
As you point out there are a lot of degrees of freedom in the
reconstruction, even more when you think about tracking. I think
that David has a mechanism for reporting nearly everything; he
should comment. That information should go into a database _and_
into the file, on a file-by-file basis, and not event-by-event.
Event-by-event is ugly, as you said.<br>
<br>
-- Mark<br>
<br>
<div class="moz-cite-prefix">On 07/18/2012 08:59 AM, Richard Jones
wrote: </div>
<blockquote cite="mid:5006B325.1030602@uconn.edu" type="cite">
<div class="moz-cite-prefix"><br>
<ol>
<li>when reading back DBCALShower objects, I will unpack them
(agnostic as to how they were made) either as KLOE or
default bcal clusters, depending on what the user asks for.
This has the "feature" that the person who wrote the REST
file might write KLOE clusters and the person who reads it
might fetch them as default clusters. This might be the
correct behavior. If not, there is another way to go:
create separate lists in the REST format for each type of
each object that one foresees, and have the writer only
populate one of them. The overhead for doing this is
negligible, but I think it is ugly. IMO, there is just one
conceptual object known as a DBCALShower, but many ways to
make it. Within the KLOE or default factories there are
many internal settings that one might switch around. Are we
going to try to save all of that information in the output
file on an event-by-event basis? Why not put it in the
database Mark was talking about, where a single entry can
cover many events, event multiple files within a production
run.<br>
</li>
</ol>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Mark M. Ito
Jefferson Lab (<a class="moz-txt-link-abbreviated" href="http://www.jlab.org">www.jlab.org</a>)
(757)269-5295</pre>
<br>
<br>
</body>
</html>