Hi Kris et al, On Tue, 08 May 2001 09:26:35 -0500 hagel@comp.tamu.edu wrote concerning ": Re: Proposal to change BrSiRdo and BTileRdo - once again!": > Christian, > You indeed risk your neck!!! > Why can the streamer not be simply changed to write only relevant > data? Fixing the Streamer method is not an option if we want to use ROOT 3 schema evolution. > As far as I can tell, that would accomplish what you want to > accomplish regarding disk space and it would keep backward > compatibility. Even if we fix the Streamer, you're not at all guarantied backward compatiblity. I recently had a problem reading files created with BRAT 1.15.6 with BRAT 1.15.3 (both ROOT 3.00/06), and it seemed to be related to BrDataObject fName and fTitle members, and that class has not been changed since BRAT 1.13.2. Also, to do a fix so that the streamer will only write out the data needed, I'd have to break compatiblity explicitly. In BrTileRdo and BrSiRdo we use fixed sized arrays. This would have to be changed to dynamical arrays and the introduction of another array to hold channel numbers. > On the issue of backward compatibility with brat_v2, I do not yet > see why it is going to break assuming I get my way and we don't > change names of classes. Well, if we want to use ROOT 3 schema evolution, which I believe we agreed upon and I think is a bloody good idea, then backward compatiblity of reading BRAT1 generated files will be broken explicitly. Also, we should not have BrEventIO write it self to disk, but rather have a special "tag" class for that purpose. This is to avoid some of the headacvhes we've previously had with modules having non-zero class version number. In fact, renaming of classes is the least of those wories. > I admittedly have not read everything, but I have been using brat_v2 > since the beginning of the year with root_v3 and I am reading > everything I have tried and it works. Yes, but you haven't used ROOT 3 schema evolution, and have not introduced a "tag" class for files. So, in essence the only difference in ROOT that you'd see is the "const"ness of methods, and a few other minor changes. Also, I think you'll find in some of the recent emails compelling reasons for explicitly breaking backward compatiblity (not just from me mind you). Uh, sorry Kris, for flooding you in emails these last few days. > Will the fact that they not inherit from BrDataObject not break > other things and break BRAT programming specifications? Since you'll never store one of the proposed classes directly in a file, but always as an array element in BrTileRdo, that is not really a problem. There's a further problem with BrDataObject, that it has a huge overhead, in that the title is hardly ever used (but of fixed size - 64 bytes), and the name is far too long (64 bytes too). In short, I'd really like to do away with that class. I understand that it was made at a time when we were not sure wether to commit ourselves to ROOT or not, and so you masked most ROOT stuff (like BrClonesArray). Now, I believe it's safe to say that we are 100% commited to ROOT. Also, with ROOT 3, a TNamed derivied class can easily be stored in a TClonesArray. > I consider this a huge outcry, but would like to hear what the mult > people have to say. So would I, but I'd also like for you to comment on the above. Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue May 08 2001 - 11:32:55 EDT