[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Still more on evio



Hi,

Some comments on Richard's comments on my comments on....

- my proposal is to adopt evio, but not necessarily change anything we already
have, at least not yet.  I agree we have more important things to do.  I propose
any new binary format use evio, but leave open what to do about "legacy"
formats.

- we could allow innumerable binary formats as long as everything is defined in
xml and converters exist.  I prefer to minimize the number of binary formats,
and I feel evio would do just fine for all of them.

- my perl tool only converts evio to xml (simple task), not the other way around
(more complicated).  I still have to add support for packets and repeating
structures (we may not bother with the latter).

Richard:  why was evio less efficient?  There's some loss in efficience in
blocking the records, but what you gain is the ability to recover a damaged file
(Hall A and C have needed this!).  evio uses fread/fwrite (c standard), not as
efficient at read/write (Unix standard), but more portable, and I don't think
much less efficient.  

Anyway, if there are some serious efficiency gains possible I suspect the DAQ
group will modify evio...what were you thinking of changing?


				Sincerely,
					Elliott
 

================================================================================

   Help feed the hungry, one click at a time:  http://www.thehungersite.com

    "Science plays a major role in satisfying the minor needs of mankind"

================================================================================
begin:vcard 
n:Wolin;Elliott 
tel;fax:757-269-5800
tel;home:757-229-2724
tel;work:757-269-7365
x-mozilla-html:FALSE
org:Jefferson Lab;Physics Department
version:2.1
email;internet:wolin@jlab.org
title:Physicist
note:A218 CEBAF Center
adr;quoted-printable:;;12000 Jefferson Ave MS12H=0D=0A;Newport News;VA;23606;US
x-mozilla-cpt:;21408
fn:Elliott Wolin
end:vcard