On Oct 23, 12:13 pm, dougx <[email protected]> wrote: > Sure, using a document wide event catcher is probably sure to be > faster than the per-element gwt default. > > The point I was making was: Why split it into the Static / Read-only / > Read-Write / Full featured for different clients? (as per the overview > section).
The main motivation is so that clients with reduced functionality (e.g., a non-live read-only mobile client, or a live, anonymous web client, or a slow web client, etc) do not waste bandwidth downloading features that are not going to be used. The follow-on benefit is that latency is improved for those environments. > Surely a hybrid model that _always_ does fast server side rendering, > and then a light(er) GWT frontend that can catch the events in the > rendered content (eg. through rendered 'onclick' events in the > statically rendered content) would be the solution in all cases? Certainly, the intent is that a server-side renderer be used in all cases, in order to reduce the startup latency between requesting a wave and seeing a rendered wave on screen. However, for live rendering, the client needs to have all the rendering logic anyway. This enables the client to function even if a rendering server is unavailable (which is the current state of wave-in-a-box), albeit with a potential increase in latency. It also enables the rendering server to balance load by only rendering important parts of the wave, leaving the client to render anything else. > What's the advantage of offering multiple different ways of rendering, > except to make it easy to support low-end devices (eg. phones), and > ignore certain browsers (eg. IE7) and why do that when the Data API > already allows people to cater for this, as shown by the read-only > mobile apps we already have using the Data API? I'm not sure what you mean by different ways of rendering. Do you mean different rendering definitions (i.e., different resulting HTML), or different control flows for producing a rendering (i.e., server- rendered / server-and-client rendered / client-only-rendered)? For the latter, the ability to provide a reasonable experience on low end devices (mobile, IE7, etc) is a very significant advantage. And even for high-end environments, since a wave rendering task can be distributed across multiple machines, server-side rendering (plus round-trip time) will always eventually be faster than client-side rendering. Architecting the application in a way that is agnostic about where the rendering comes from is an important property for scaling up to handle large content with low latency. Writing a separate server-driven application using the Data API is certainly an option, and we're not discouraging anyone from choosing that architecture. But architecting a rich, full-featured client application in a way that can easily be scaled along the spectrum of low-end to high-end environments is more cost-effective than developing many separate, disparate clients. Forcing that architecture on the feature-complete application also reduces its startup latency by delivering the important parts first (i.e., rendered HTML). Excellent questions! -David -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
