Sorry for the flames

[Ian Schneider <Ian.Schneider@ars.usda.gov>]

*************************************************
Message from the sgt mail list.
*************************************************

Rich Schramm wrote me:
Ian,

I suggest you save your flames and go try and find anything better -
esp. at the price!  I've found SGT toolkit to be quite useful to build
real applications. Is it perfect - no but nobody said you have to use
it. Don certainly has put a lot of work into something that he is quite
willing to share with the rest of us as a service - something that he
doesnt have to do - as he has done for 20+ years beginning with Plot5. I
for one appreciate it!  If you have some constructive input then fine,
participate - but please behave and appreciate what youve been given!

Rich Schramm


So...
"...but please behave and appreciate what youve been given!"""

I apologize for my angered words of yesterday. I was misbehaving during
a moment of frustration.

" I for one appreciate it!  If you have some constructive input then
fine, participate ..."

I was attempting to give constructive criticism for what I saw as some
short-comings of this product. I must say that anything free that works
is good. If I didn't care I wouldn't have spent the time to sign up for
yet another mailing list.

Let me reconstruct my criticisms AND appreciations:
Appreciations:
1) I was able to quickly build and customize a graphing tool for my
application.
2) The graphics are groovy and the performance is adequate (I'm on linux
so I don't receive the VolatileImage benefits of Windows).
3) The package is flexible and in general, has documentation.

Constructive Criticisms:
1) As I mentioned yesterday, PropertyChangeEvent's are expensive and in
high performance graphics applications, should be avoided as a means for
heavy communication - in this case repaints. PropertyChangeEvents are
typically for beans and bean editing frameworks which utilize them in a
very systematic manner, not an ad-hoc means of communicating. For
instance, all of the various editing dialogs can be thought of as bean
editors. The point about the demos should be taken seriously. This code,
which is from gov.noaa.pmel.sgt.demo.PsuedoRealTimeData is bogus
(Annotated with my comments) :
<snip>
// one wasted copy
SoTRange.GeoDate oldRange =   
  (SoTRange.GeoDate)xRange_.copy();

  tend_.increment(majorIncrement_, units_);
  xRange_.end = tend_;
// useless as ANY propertyname and ANY values(including null) do the
same thing
  changes_.firePropertyChange(
    "rangeModified", 
    oldRange, 
    xRange_);
</snip>
As is this:
<snip>
// useless as ANY propertyname and ANY values(including null) do the
same thing
changes_.firePropertyChange("dataModified",
                            new Integer(count_),
                            new Integer(count_+1));
</snip>
There is extra, meaningless stuff going on.

OK, so sorry for the unconstructive comment of yesterday. I hope I laid
that out better.
Perhaps a better strategy is the use of a known awt or swing listener
interface such as ChangeListener or if more specific functionality is
needed, some type of direct interface which doesn't fire events.

2) GeoDate. When running a profiler on my application, I noticed a fair
amount of memory was consumed by GeoDates. GeoDate contains a large
number of integer fields. The same functionality could be accomplished
(if needed) by a class using the Expert pattern. That is, this class
knows how to add, increment, and do other such operations with Date
objects. Essentially, a date is a long. Because most applications of
GeoDate seem to be immutable ( or should be ), there is a lot of extra
overhead for those who don't need it.
The other concern is the lack of synchronization for the static Calendar
that GeoDate uses internally. My usage of sgt is very multi-threaded and
although I haven't noticed problems yet, I anticipate that strange
GeoDate behavior can be traced back to this problem. For an example,
look at the source code of java.util.Date which does the SAME thing but
is syncrhonized.
GeoDate is kinda embedded everywhere so I guess it's kinda late to
remove it, but it could be changed to a Facade object where the external
API doesn't change, but you offload the real work and field storage to
some other object so IF the user is not doing date arithmetic, he/she
does not have to incur these additional fields.
GeoDate also has it's own static fields for identifying pieces of time
(SEC,MSEC,etc.), which, last time I checked are just a subset of the
SAME in Calendar.
Another source of frustration is this:

GeoDate i = new GeoDate(System.currentTimeMillis());
GeoDate j = new GeoDate(System.currentTimeMillis());
// false
System.out.println(i.add(j) == i);
// true
System.out.println(i.increment(10,GeoDate.MSEC) == i);

This is one of the reasons I got angry yesterday. Sometimes GeoDate is
mutable, sometimes not (and its not clearly documented) !!!!!


3) I apologize for the harsh words about the package being "shaky at
best". I said this because while trying to track down my problem, I came
across JPlotLayout (@version $Revision: 1.47 $, $Date: 2001/12/13
19:07:06 $) which I noticed has a ~300 line constructor alone and a ~550
line method which apparently does everything, including slicing and
dicing. When I see this kind of code, it makes me scared. It works, but
you must wonder for how long and why your bugs aren't being fixed
sooner. I noticed it is basically one big if-else section which
determines what type of internal structure to create dependant upon
SGTData, SGTGrid, etc. and the various xxxCollections. So this means
alot of byte-code is always loaded, but usually not ever used. A better
way would be to delegate this logic to some internal, lazily loaded
class. Two benefits - 1) save start up time by avoiding huge bytecode
loading 2) make the code more maintainable and understandable.

END OF CONSTRUCTIVE CRITICISM

Thank you Rich, for pointing out that I was acting like an idiot.
And thank you Don, for producing sgt and doing the qrueling work that it
must have required.

I will be more than happy to assist in any efforts with sgt as we are
planning on using it more and once my code is more completed, will be
glad to share.

Thanks,
Ian Schneider

*************************************************
To remove yourself from this mailing list,
send mail to <Majordomo@epic.noaa.gov> with
"unsubscribe sgt" in the message body.