I just sent a message to users asking for feedback re revamping the
callback mechanism. I'm hoping some developers will engage me in
discussion of this as well. (Tim and Miguel, I know you two are busy
and interested -- just point me in the right direction.) On this side
of the fence I'm hoping we can discuss what the options are for
delivering whatever comes of the user discussion.
Being new to Java programming, I'm sure anything I write could be
written better. Still, I do think it's beneficial to see processes in
action even at the conceptual stage. (I'm a prototyper, not a
theoretician.) I'm putting up prototypes at
http://www.stolaf.edu/people/hansonr/jmol/test/json/callback.htm.
So, first question:
It seems to me there are three fundamentally different types of
callback needs.
1. simple value
One is a very simple delivery of a single parameter value -- what file
was loaded, whether there was an error loading the file, what frame is
being displayed, which atom was picked -- that sort of thing. No real
problem there.
2. more involved value
There are some values that one doesn't really want to deliver every
time they change (like orientation or measurement information), but
still you want to notify the application that they have changed and IF
there is an interest, they can be delivered in a second request. Sort
of a checkStatus/getProperty idea.
3. streaming information
This is the message log and perhaps the stream of information arising
from clicking on atoms.
Q: Does this sound about right?
Q: Is there a very easy way to handle the simple "streams" of
information that isn't text. Is that a Java Vector, maybe?
Q: What's the best way to make this work with the app and applet?
I see how the idea of a common interface would work -- and we
basically have that already, because the callback mechanism currently
works out of JmolStatusListener. But this is a little different
because basically the app and the applet should really have a COMMON
class, I think, like Viewer, or part of Viewer, that collects the
information for either and then, only in the "getProperties" side of
things, at the very end, would the two diverge. (Now that part sounds
like an interface with dual implementations.)
Q: Ideas for exactly where this should fit in? A new class? A new
interface? Extension of the JmolStatusListener interface? Two new
implementations of a class and one new interface?
I don't think this should be a terribly difficult thing to set up. I
figure whatever I implement on my own will just form the basis of
whatever we end up with anyway. But the closer I can come at this
point, the better -- and the more I'll learn.
Thanks,
Bob
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
