----- Original Message -----
From: "Miguel Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, December 14, 2003 4:10 PM
Subject: Re: [Jmol-users] Synchronizing distributed molecular models
Hi Miguel,
thank you very much for your prompt reply!
> Christian,
>
> > For use in online-tutoring I would like to keep several
> > *distributed* copies of the same Jmol-displayed molecular
> > model *synchronized*.
> > There is no problem, I suppose, if I restrict myself to script-
> > driven interaction with the model (displayed as an applet),
> > because in that case I have an easy handle on state changes:
> > I can simply distribute the script commands to all other
> > copies running elsewhere on the net, as required.
>
> Sounds right.
>
> One thing isn't clear to me. Are your distributed 'viewers' going to be
> standalone Java applications that incorporate Jmol ... or are you trying
> to do this in the context of a web page, using the JmolApplet?
No, no, no: Not in the context of a web page at all. This is for
real, live, one-on-one tutoring, or, alternatively, for group
teaching / group discussion over the Net.
Currently I am just displaying the JmolApplet in a Window that
is managed by my distributed presentation system. This is because
I already have an "applet loader" that can (basically) load *any*
applet (including the JmolApplet) in a distributed fashion - that is,
if it is loaded from the file system of one participant, my distributed
presentation system sees to it that it gets loaded *locally* from
the machines of *all* other participants as well. (Applet parameters
are taken from a simple Java properties file, so I do not even
have to *parse* anything at all...)
But there are different levels of integration with my existing
distributed presentation system that I might try to achieve.
Those presentations are script driven (though I may have to
improvise anytime). So, instead of just having Jmol run in an
*independent* window, as an applet for example, it might be
preferable to have it *embedded* within a presentation
document that involves text, formulas and other (static)
graphics: essentially, to have it embedded "plugin-fashion".
(I use LaTeX & friends to create text, formulas and 2D graphics:
3D models are late add-ons that I would now like to integrate
as well.)
<snip/>
> > Can give me anyone more knowledgeable
> > in the design of Jmol than myself (a newcomer, actually) an
> > off-hand reply that might point me in the *right* direction
>
> I think you are on the right path.
>
> > - even if it would amount to telling me to simply *abandon* the
> > idea of the kind of direct model status observation that a "perfect"
> > solution for synchronized distributed molecular models would
> > require?
>
> I don't think you should aband this. It sounds like good functionality,
> and I don't think it will be difficult to do ... from the Jmol side.
>
> You should be able to stage your development so that this type of
> distributed synchronization comes later in your project.
>
> What kind of timeframe requirements do you have?
I have no *externally* imposed timeframe, I am just pushing
*myself* to offer as much functionality to my students as I
can... I have already (mostly) achieved the kind of distributed,
synchronized 3D model display that I want with JavaView
(see www.javaview.de) and with (simple) Java3D models
constructed by a "model generator" of my own - but Jmol is,
for the purpose of displaying molecular models, much easier
to handle than JavaView (my main task is tutoring - *not*
software development, not even 3D model construction,
you see: I am just *dabbling* in software development in
case my current tools leave something to be desired - and
they frequently do... Though, I should add: I have been a
"professional" (C/C++)software developer for several
years, but that's behind me now, or so I hope...) Then,
too, there already exists a considerable database of
useful molecular models for Jmol to display. Constructing
new molecular models, if I really have to some day, is clearly
easier for Jmol as, for example, JavaView - or Java3D
(with the help of my own, more mathematics-oriented model
generator).
> It sounds like a challenging project ... how much Java development
> experience do you have?
*Java* development? - not much. But the kind of groupware
system for online-tutoring (distributed presentation and
whiteboarding - in fact quite frequently scribbling on the
presentation itself) that I want (and to a large measure already
have and that I have been using for some time now) was
quite easy to develop. I have essentially pulled this out of
Merlin Huges' et al. "Java Network Programming"; Chapter 33,
to be exact ;-) I hope you realize that I want the famous 80%
of functionality for 20% of the work ;-)
Jmol would be a "verrry nice to have" add-on to my existing
distributed presentation system. Even just synchronizing the
*loading* of the *same* molecular model, without further
synchronizing its state upon interactive modification by the
participants, is already a good thing to have - though proper
synchronization of the whole state of that model, over the
whole duration my presentation, would be even better -
so much better in fact that I can *hardly* resist the temptation
to get it: hence my questions...
> Have you played with Jmol source code and built the example .java viewer
> application?
No, not yet. I am somewhat shy about getting too close
to "someone else's" source code ;-) In particular, I *much*
prefer to stick to a solution that does *not* involve (incompatible)
changes to existing code. I also prefer *not* to make use of
knowledge that is not part of an official interface if I can help
it. (Such sins will likely come back to haunt me, my experience
tells me.)
But I will now have a closer look at the Jmol source code.
I just felt that someone who already knows Jmol well, as
you certainly do, could stop me *early* from starting to
run in a wrong or unusually difficult direction...
> Are the distributed copies all displaying the exact image?
Yes, that's the idea. We are discussing some chemistry problem,
and, in that context, are looking at a molecular model - and
perhaps manipulating it. It's like a virtual classroom, you see
(but no video please! - we cannot afford the network bandwith:
we want most of that for our *audio* links). If we don't see all the
*exact* same presentation, we will find it very difficult to
communicate clearly and succinctly...
> If so, then the easiest thing will be to blit the entire image around ...
> that may not be what you are looking for ... because it would turn this
> into a rather trivial project :-)
There is something to that. I started out doing my tutoring
with "application sharing" on Windows, using NetMeeting
(which was even more trivial than what you are suggesting -
but a similar "blitting around" idea is certainly involved in this
case). BTW: I am all in favor of "trivial projects" - to paraphrase
Albert Einstein: "Projects should be as trivial as *possible*, but
not *more* trivial than that." As it turned out, the Windows
NetMeeting approach was *too*trivial* to succeed completely...
However: (1) application sharing is limited to Windows-
Windows cooperation, which is already A Bad Thing in itself.
(2) As to the blitting approach more generally: some of my pupils
are connected to the Net via relatively slow dialup-lines.
Since we also want good audio-links, blitting too many raster
images too often does not seem such a wonderful thing to do.
Certainly, NetMeetings Application Sharing is hurting the
quality of our audio links noticeably (though, if we are willing
and able to pay for it, we can arrange a parallel conversation
over ordinary phones).
If, instead of blitting many images, I just distribute the essentials
of new viewing information (like scale, view direction, translation,
etc. which amounts to a few doubles at worst) after one of
the participants has finished(!) resizing, rotating, or moving a
shared 3D model, and if I "interpolate" between the recipient's
current model state and the new (stable) state received over the
Net, modifying the local 3D model in "slow motion" from current
state to new state, I can get away with *orders*of*magnitude*
fewer bytes transmitted in the process - and still have very nice,
intuitive behavior of the model: (almost) no transmission or image
update delays, no image stuttering, no bad image quality: but the
"real thing" for each and every participant...
I am well aware that the "market" for my admittedly more difficult
approach to synchronizing the display of molecular models may
go away in the near future: namely, as soon as transfer speed over
the Net improves by at least an order of magnitude for *all* of my
pupils. But I want to do a first-rate tutoring job right *now*: so
here is my problem, and hence my need for your educated guess
as regards the difficulty of what I am hoping to achieve with Jmol
(whether semi-independent Jmol applet, or completely embedded
Jmol "plugin" for my scripted presentation documents).
Perhaps I will experiment with your "just blitting around" idea as
well, nevertheless - though, given my somewhat negative earlier
experience with application sharing under NetMeeting, I am
somewhat hesitant to do so.... (I hope you realize that I might
conceivably have to blit those images out to N students, for N
noticeably larger than 2! - currently the only "logical" limit to the
number of participants for my distributed presentation and
whiteboarding system is the number of TCP/IP connections
that the server process, running on my own machine, frequently
just a modern but otherwise ordinary home PC connected to the
Net via 1000kbps downstream / 300kbps upstream cable,
can have open at the same time...)
Best regards - and thank you for your excellent work on Jmol,
Christian Stapfer
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Jmol-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-users
