Lists Home |
Date Index |
From: peter murray-rust [mailto:firstname.lastname@example.org]
Good to see you back here, Peter.
>Of course it is! We covered much of this in 1998. The new things are
increased frustration and possibility that with
> current technology and mindset we might actually put it to rest
Yes. OTOH, I don't know if that much has changed other than in the last
eight years, more people have climbed the learning curve to understand
what the original markup community told them: an HTML web browser is a
cul de sac. Any wrapper language browser is. That the page metaphor
won the first web war wasn't inevitable but understandable. It is
> I generally agree that XML plumbing needs to be outside of the
> browser as services,
>The vision is of a generic client onto which domain specific facilities
can be installed.
Then the client is just a container because eventually one has to choose
the rendering client/plugs, the communication API among them and the API
to the operating system and network. Because the operating system might
subsume the APIs, this starts to look a lot like XAML and its
antecedent, the MID. Doesn't this come down to the container
>Thanks for the suggestion. I am sure that web3d will have use here. But
the viewer needs to have a lot of chemical
>semantics. We already have that in Jmol which performs as well as many
hardware-accelerated alternatives. Note that 2D is
> complementary to 3D in chemistry - both are essential.
2D and 3D are essential. X3D has a 2D layer for that. The question I
have is do you want the semantics to be in a separate class that talks
to the 3D/2D nodes, or built into them? In X3D, you can add classes
for that, then use the rest of the internal message machinery.
Communication with the X3D browsers is easier via the SAI API that
replaced the EAI.
Regardless of the rendering apps you use, you will also want to make
this environment suitable for real time collaboration much like the 3D
builder packages if more advanced and more focused on chemistry. The
ability to play with the models in real time with many participants is a
game-like environment and nothing new has to be invented; just
specialized. You absolutely want the XML handling (pure XML, not the
application semantics) in a different library.