> > well, i've cooled off now and so apologize for the flame (which used east
> > coast speak -- here's the west coast version)
> At the risk of heating you back up again...
> > i'd like to suggest that those of you working on epics software which is in
> > general use remember that there may be people out there who
> > depend upon the possibly unusual or undocumented behavior of that software
> > it would be nice if all all visible changes were well documented,
> > it would also be nice if all public interfaces were well documented. i was
> > not able to find on the web (perhaps someone could tell me where i overlooked
> > it) any info on the adl file formats (old version and/or new improved version)
> > for general information, we are using this information for 3 projects:
> > -- a library of routines which create .adl files (we generate the
> > majority of our screens by software, not a human editor)
> > -- converting medm .adl files into dm .dl files to allow dm and medm
> > to be used interchangeable (we prefer dm performance but medm editor)
> > -- continuing to develop john winans applet which will eventually be
> > able to display medm .adl files within netscape
> I think (and have always THOUGHT) that this java app is a wonderful idea. I
> regret that the MEDM and DM file formats are incompatible. I would have not
> influenced the divergance, but it is/was my understanding that DM was having
> its file format changed for whatever reason. Fred mentioned that to me when
> I was asking for clarification of some aspects of it. Fred then mentioned a
> few ideas he had that he wanted to see added to MEDM's file format and that
> he was going to add them since DM was going off on its own anyway. I responded
> with "if they are different, they are different. Lets fix the bogosities while
> were at it and reduce the size of the file by 50%." So we did.
The ascii format was created specifically for providing an upgrade path so
that existing displays could be used after additions/changes were made
to edd/dm. Since dm uses only the binary format, the compactness of the
ascii files was not considered an issue.
When medm work began, it used the edd/dm ascii format and diverged from
there. At that point in time there was a discussion about keeping the
file formats in sync. The author of medm at that time felt this was not
an important issue.
Edd/dm ascii format has also diverged since then to support new features
and functionality. The work done recently so that medm display files
could be imported into dm was a conversion from medm ascii format to edd/dm
ascii format followed by saving the ascii files in binary format.
The issue here may really be one of backward compatibility vs upward
compatibility. It is reasonable to expect that display files, etc. from
one version work with the next version of a tool. While it would definitely
be desireable, it may be too much to expect that new versions of display
files work with older versions of the same tool or others. Having advance
notice about such upcoming incompatibilites with tools you're using would
certainly be in order, though. As Chip mentioned, communication and
documentation are essential to prevent other problems like this. As a tool
author, this point is one that I intend to keep in mind for future releases.
It is unfortunate that the suggestion of a collaboration to merge medm and edd/dm
did not meet with the same enthusiasm and support that other EPICS collaborative
efforts have. Had this been the case, the differences would have been resolved.
(and maybe tech-talk wouldn't need to invest in a fire extinguisher :-) ) If
this compatibility is important to the EPICS community, maybe we can still
collaborate on this issue and try to maintain consistency in the display list.
Or maybe just having them documented is sufficient. Opinions?
> I don't want to ask who came up with that horribly unorganized mess of a
> format in the first place. I suspect that it is the same $#&&^% that came up
> with the unbelievably odd message-button behaviour (that has hopefully been
> fixed by now) that I recall from 1992.
The "unbelievably odd behavior of the message button" in dm was mandated
by the GTA project, the project responsible for the majority of EPICS edd/dm
funding at the time. It has since been changed to follow the design as
originally intended. (FYI, the person responsible for the "horribly unorganized
mess" was not the same $#&&^% that implemented the message button. Gotta keep
our EPICS history straight :-) )
> So anyway... the point of today's rambling is to let the folks at JeffersonBAF
> know that my Java stuff is not exactly in sync with the new MEDM format
> either. It needs to have the RGB parser changed to read the 3-byte RGB
> values instead of the R=, G=, B= cruft that it had in it when I sent it
> to you. You might consider adding a little logic to let it read both formats
> automagically... though I'd rather see the old format not supported at all
> since it adds something like 70KB to every screen and
>taked several seconds to parse using my (admittedely less-than-optimal) logic.
Deb and Jeff
p.s. We suspect that since medm supports only an ascii format it will be very
difficult to beat the compactness of the edd/dm format--this approach "taked"
less time to parse, rampant "bogosities" and all. (All "flaming" aside, your
decision to implement such changes does make sense for medm. )
- Navigate by Date:
Re: Should ai, ao records have RAWH, RAWL? John R. Winans
Re: Should ai, ao records have RAWH, RAWL and MORE ! Gabor Csuka
- Navigate by Thread:
Re: FLAME medm watson
Re: FLAME medm John R. Winans