RE: [ubl-dev] UBL payload and client-server integration tools

["David RR Webber \(XML\)" <david@drrw.info>]

Fulton, 
  
Another option in a "Microsoft-only" world is to deploy to the client as
an html application (I think there is an equivalent browser mode for
Netscape / Mozilla too - but not tried it - requires some clever
configuration files).  That way the js libraries and XML templates
(UBL) reside on the client harddrive. 
  
Response time is what AJAX is all about however - minimizing what needs
to go down to the client in all respects - buttons, logos, entry
fields, until they are really needed. 
  
My solution to the DOM tree issue is to avoid traversing it!  Instead do
direct assignments using the template as the lookup to the fields by
document.fieldname - much quicker!  Again - delaying this also until
the user hits "Send" is the key - at that point they are not so
concerned about speed - because they are done with the task. 
  
The beauty of the B2B deliver is of course - you can defer those till
later when off-peak bandwidth is available. 
  
DW
 


 -------- Original Message --------
Subject: RE: [ubl-dev] UBL payload and client-server integration tools
From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
Date: Tue, November 14, 2006 12:34 pm
To: david.lyon@preisshare.net, ubl-dev@lists.oasis-open.org

David Lyon,

With respect to your view that "computers are a lot faster today
...latency
is not a real problem now," that is not the perspective of today's RIA
designers. They are at risk of being crunched between two opposing
forces,
limits of IT infrastructure "supply" and user "demand."

RIA designers need to fight for every millisecond reduction in response
time
budget to offset infrastructure limits. Their RIA transaction-oriented
applications are contesting for client, server, firewall, and network
resources against new or growing services such as VOIP, IPTV, sensor
inputs
and "chat." Indeed, XMPP(jabber)is more likely to be an enemy rather
than a
friend to business-transaction-oriented RIA. Enterprise internal
networks
often have less available headroom than the Internet and may have been
engineered more for throughput than response time optimization.

With respect to demand, your quote "Speed is, like Einstein said,
relative,"
is apropos. Speed is relative to user think time and expectations, and
there
are quite predictable user perceptions regarding what is "sluggish"
response
time. The RIA designer has to accommodate user perception, even if the
user
is in a branch office or is using cellular data service (e.g., EV-DO).

Given the crunch between supply and demand, within the RIA world, there
is
something an XML backlash, because of its overhead. For example, below
is an
advisory from an RIA tools oriented site: 

"The benefit of electing the "return XML" option is "...a nice, clean,
standardized interface on the server..." Well, it is good that RIA
developers recognize the benefits of XML and standardization.

Unfortunately, the advisory continues with the response time downside:

"As an example, JavaScript has no good high-level support for [XML
parsing],
so you will need to traverse a DOM tree to extract the data you need -
probably translating it into some intermediate JavaScript data
structures in
the process. Two or more passes over the same data does not a snappy
application make, and your performance may suffer from this approach." 
http://dojo.jot.com/RemoteScriptingRevisited

Judged from an RIA perspective, a typical UBL transaction is a giant
clot of
text to be either parsed or generated. At the same time, as the RIA
developer jettisons what looks like overhead, the result probably will
be a
transaction that is not only non-standard, but in many cases not fit for
purpose. IP built into the standard (e.g., what currency is involved in
the
transaction, what tax domain) will be forgotten.

Note that, network and server-side considerations may be even more
important
than client-side parsing, so scripting limitations are just the "usual
suspect."

We can of course leave the client-server RIA designers to their own
devices,
but what I have been looking to accomplish is to see if there is a way
of
working within their performance framework, while preserving the
essential
value proposition of UBL. 


Fulton Wilcox
Colts Neck Solutions LLC


-----Original Message-----
From: david.lyon@preisshare.net [mailto:david.lyon@preisshare.net] 
Sent: Monday, November 13, 2006 6:49 PM
To: ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] UBL payload and client-server integration tools

Quoting Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>:

> One further point with respect to "light" is that it is extremely
difficult
> to "buy" latency reduction. Internet 2.0 "mashups" (front end, often
client
> side applications that depend in invoking multiple applications, services
> and databases) have very constrained response time budgets, so they must
be
> built for speed. Indeed, many client-server applications of the 1990's
> (which themselves often were "mashups") often had sluggish performance
> because they were built for "richness" rather than speed.

That was then, this is now. Computers are a lot faster.

Everything has changed since those days.

Latency is not a real problem now. Stuff like XMPP protocols deliver  
instance presence anywhere around the globe. Along with any XML payload.

Speed is, like Einstein said, relative.

Regards

David

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org