There's been a lot of buzz and other noise going on about how the next generation of Web-based applications will be implemented. The problem that is trying to be addressed is not a new one: HTML forms widgets are truly awful for anything beyond the simple "contact form" apps that informed their design and people want (or think their customers want) richer desktop-app-like interfaces. More than just browser-embedded applets, the trend seems to be toward client-side "runtime engines" that get both their UI definitions and data via XML over HTTP and "web services" interfaces. Examples include Mozilla's XUL, MSFT's XAML, and Macromedia's Flex.
IMO, this trend (if it pans out in reality) puts AxKit in a positive position for faster and wider adoption. AxKit lives on the notion of "one source, many views" and, since the interface definition languages that are emerging all seem to use XML as their syntax, for us, delivering such "phat client" apps are simply another optional runtime transformation. At the highest level, AxKit makes delivering phat client data-- while still offering the same application as HTML for maximum portability-- no more complex than delivering the same narrative article as either HTML or PDF; its just an alternate style that is applied to the common source based on the user's context/preferences.
I've played a bit with Mozilla's XUL (there's even a sample in the book that renders a simple data-entry app as both HTML and Moz XUL, at the user's choice) and it seems like a natural step to me. I'm wondering what folks here think, and if there's anything we (the AxKit developers. or the larger community) could do to foster experimentation in this space easier or to make implementing such apps more straightforward.
Discuss...
-kip
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
