[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Why XML for Messaging?


why xml for web games
Hello Len,

The rich clients seldom discussed here are the game and 
real time 3D clients.  XML is trapped here in a 
document/forms mindset due to our origins in 
document and database technologies.   

Didier:
Its even worse, we do not actually have common rich apps defined from XML
and running on clients. We are still trapped in the mainframe world.

A 3D component can fit into a 2D layout form. Since our screens are 2D and
based on virtual screens (i.e. windows) then then 3D components can be
embedded into 2D layouts (may even take the entire screen). Moreover, this
3D component can be collaborative and trigger events to be used by other
components.

The simulation and game clients are rich, use messaging, 
and transfer objects.  Distributed systems such as XMSF 
are already doing much of this.  The Blaxxun SharedEvents 
extension is already doing this.

Didier:
I tried googling for XMSF but got a lot of garbage. Any link?


The language of the next generation is the language 
of the *viewpoint* (not a philosophical viewpoint:  
a virtual camera++).  Thus, not XAML or XUL. 

Didier:
Maybe Len, but we are still in the dark ages. To move to new UI paradigms we
need a renaissance.... XAML and XUL or any other framework allowing us to
use the processing power of clients in a necessary step. Don't forget that
we seriously regressed on that front in the last years. Another point, my
numerous hours in the usability lab taught me that unless we have better
input devices. Navigating in 3D is really not easy with a mouse. Maybe we
need a new device like a glove and a gesture language. Or even better a
sensor able to recognize the gesture. Games will probably be the first to
use such devices. But games like applications are expensive to install on
each and every workstation in a company. Here us what we need:
a) Software that can be downloaded from the web without any installation
costs. Centrally delivered and automatically delivered from there.
b) Software using the local processing power. Servers should be common data
storage not application processors.
Speaking and hearing with our community lead me to observe that the current
state of the art is:
a) applications running on servers,
b) clients reduced to the role of terminals and like one of our colleague
said in this group. We do this in color and animations. Small improvement
over 3270 terminals :-)

We need to bring rich apps with reduced cost of ownership to users. Then,
from there progress will resume. We regressed for the "reach" with "poorer"
applications. We now need to keep the "reach" with "richer" applications.

Cheers
Didier

<<attachment: winmail.dat>>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.