[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