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. 2) Acclaiming these as "next generation" things is a blogger thing to
do (*ducks*). What's new is the Web at large -- that is the Web as
we knew it in '95 and that hasn't changed a bit since -- and BigCos
like MS are catching up with it. But let's not be blinded by that,
I've seen *government* contracts (read, not exactly early adopters)
for precisely this two-three years ago. And yes, AxKit was in the
game ;)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.
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.
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.
Heck, Macromedia isn't supporting it because it's not working. They're supporting it because they don't have the choice in the application space. To stay in the evil empires, Oracle isn't making SVG+XForms the interface to its next version of its db suite just because they think the WG members are magnetically attractive (we are, but that's another story ;). I won't mention *very* persistent rumours of SVG showing up natively one of the more interesting recent browsers...
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!
You also forgot XBL, which is coming to another browser close to yours soon :)
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.
If you look on xml.com, you'll see an article on using Cocoon for EAI. It doesn't go into much depth technically, but exposes an interesting usage scenario (as well as a bunch of flaws in Cocoon's design). There's definitely something for the axkittens to chew on in there.
Do you have specific technical ideas that we should work on to facilitate this?
-- Robin (who'll prolly be offline for a few days)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
