[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] UBL payload and client-server integration tools
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]