Rahul Jain wrote: > > LocalAppBroker: I don't have that. Send it embedded in the LocusML. > > Hmmm... the way I see it, the last step is not necessary. The local app > broker or whatever should contact the Hub app broker and say I have data > in such and such format (use MIME for this?) could you please list the > available viewers? The user would then be presented with a list of viewers > and would choose to download the viewer, save to disk, etc. Sorta like the > way Netscape does it. That's a good point. Netscape does deal with the same problem and uses MIME. I do like the idea that the skeleton locus is a "browser" that browses LocusML (as Netscape browses HTML) with GUI scripts attached (as Javascript is attached to HTML). The effect is that the GUI itself is being browsed and is transient. I just like that idea. I think it's pretty clever. The alternative is to download the GUI script via link (as Humberto mentioned), which is more like running a Java applet than a Javascript. The big question is how complex will the GUI be? Regarding MIME, Loci will have to deal with unknown datatypes, just as Netscape does. So Loci can present the user with a dialog box with Specify Viewer, Get Viewer, Save To Disk, Cancel. If for example, the user chooses Get Viewer, Loci will have to contact an IAB or MAB (Hub). Maybe it is best to take the beaten path and use Netscape as a model. But what about binaries? When Netscape asks if you want to get a viewer, it gets a binary program. For Loci we were talking about a Python script. That'd sure help with portability issues. But if we are now talking about a once-in-a-while situation where a new viewer is needed, could we just have binary viewers downloadable and skip the script? I'm looking for a model that would give us a clear-cut case for doing something different. It seems we could once again go either way. Jeff -- J.W. Bizzaro mailto:bizzaro at bc.edu Boston College Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/ --