[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