Howdy Kipster,
Kip Hampton wrote:
There's been a lot of buzz and other noise going on about how the next generation of Web-based applications will be implemented.
Yes, there's a lot of talk about all this but there are a few facts that just don't seem to make it out.
1) These things only come into existence because the browser makers are mostly incompetent. Ergo, all that happens happens pretty much around the browser more than in it. The exception is Mozilla, and even then there appears to be a certain amount of discontent about how they develop and push (or rather don't push) XUL.
Obviously, this all leads back to your point, which is that we might still need to deliver HTML (hopefully not for too long) to dumb clients. IE6 gives new meaning to the "dumb terminal" syntagm.
I wouldn't bet on seeing the demise of HTML anytime soon. Its a perfectly serviceable (and deeply entrenched) presentation format for publishing documents electronically. It sucks for building applications because it was never really intended for that role (stateless, minimal widgets, etc.) but I doubt that the World is going to throw the baby out with the bathwater given the wide area that it *does* cover appropriately (if not ideally).
The HTML-based e-commerce explosion didn't happen because the markup made things nicer for developers or because it created a richer UI experience for users; it happened because, past a certain point, companies could count on the fact that everyone from Joe Uberhacker to Grandma Moses had an application installed that rendered the markup that implemented the order form. That need for a lightweight interface that will run on most any platform irrespective of the clients' OS and processing power is not going to go away.
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.
Hmmmm. You cite the brand new and not available solutions from the Two Most Evil Companies On The Web Now Netscape Is Dead, but neither SVG nor XForms, which not only are standard and available in real implementations, but the former is actually far more deployed than XUL+XAML+Flex united! Bad Kip, no cookie.
You're so cute when your zealotry shows... ;->
I didn't leave out XForms and SVG on purpose. In fact, Xforms seems a natural source grammar for phat clients. *But* as you well know, XForms is intentionally presentation-agnostic so it either needs to be transformed into something like XUL or HTML to render the widgets, or consumed by an Xforms-aware client that knows what to show on the screen based on the elements in the XForms grammar.
SVG might be fine for the presentation part, but it seems far too low-level to me to be practical-- at least at this point. Contrast drawing a beveled rectangle with some text inside of it that is bound to a pile of client-side DOM-manipulating ECMAScript to make it all go *doink* when i click on it vs. a simple <button> element in XUL that gives me what i really meant in the first place, for example.
Oh, and that doesn't even take into account the fact that Flex supports SVG natively, and that by the time XAML hits the real public in another three years it'll also have SVG and XForms since the projects to do that are underway.
Good to know.
In addition to that, there are hundreds, likely thousands of intranets out there using those technologies, already, today, and for the past few years. Not to mention mobile content which is at long last becoming a reality. So I know that it isn't the Web as you see it because it's not public, but it is 1) the Web nevertheless, and 2) the desire to have better forms and better UI is driven by the complex things one tries to do in an HTTP context, and 90% of that is intranets or back office systems.
Forgive me, but unprovable claims about what X number of intranet projects might or might not be doing (with no way to check how it all really worked out in practice, and how much it cost to develop. etc.) carries no weight when compared to technologies that I can try for myself today using freely available, OSS applications (Moz + XUL). Maybe it worked out great, maybe it didn't; but until I can look under the hood (and see the size of the bald spots among those charged with making it work) I'll remain justifiably skeptical.
So that's for the rant. I don't rant for the sake of it (this time), but because you put forth an excellent idea for AxKit's future yet imho purposedly not list some of the more likely targets!
Like I said, I didn't leave XForms and SVG out on purpose-- I mean, why would I, because I'm such a staunch supporter of corporate bullyware? Put down the crackpipe and back away slowly... ;-> Seriously, if there are tools and examples using XForms+SVG to create rich clients that are out there and can be seen and used today, I'd love to see them.
Note: I'm not at all married to XUL as the end-all solution in this space. I really haven't used it enough to say one way or the other yet. But the fact that I can try it out for myself, now, today, means a lot. Its important to note too that Moz+XUL offers more than just richer form controls, there's the easy access to methods for things like fetching data via XML-RPC and SOAP to consider.
IMO, this trend (if it pans out in reality) puts AxKit in a positive position for faster and wider adoption.
It's there already, and I certainly hope it'll pan out on the Web at large as it would make it interesting again after quite a long sleep, however I'm not holding my breath (yet). That being said your invitation to think about ways in which AxKit could make itself useful in this domain still stands regardless: there is much need for XML handling/publishing/routing solutions inside the firewall. And AxKit should surely make a landgrab there.
/me nods
Do you have specific technical ideas that we should work on to facilitate this?
Matt's point about better forms handling mirrors a lot of my thinking. Past that, I think that creating drop-in components (Providers, Plugins, etc.) that make setting up "web services" easier seems a logical step too.
-kip
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
