Robin Berjon wrote: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.
I'm not betting on HTML's demise, just eagerly waiting for it to be deprecated (or improved) in the app-building space. I know that it'll be around for quite a while, and that unless something drastically better shows up (sets of minimal improvements are not enough, some radically new functionality is needed) it'll stay there. Hence the need to find the right abstraction for UI things and applications, in order to be able to serve whatever is needed, even HTML.
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'm *always* cute, and sometimes my zealotry shows ;)
I didn't leave out XForms and SVG on purpose.
Ah, that's not what you said on IRC!
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.
Yes. However, there are issues here. XForms also defines the processing model, and if you translate it to XUL/HTML/whatever you either lose that (and only keep the form abstraction, which is a bit boring on the side) or have to also send a bunch of script that emulate the XForms model so that your browser works like an XForms client.
I can't find the link right now, but IBM has a tool that does exactly the latter.
One thing that also gives me hope in the XForms space is that a lot of companies are eager to use it for their internal form filling needs. And since it's available as a plugin for most major browsers, there's hope that it'll spread fast through such means. But since it only just came out, it's hard to guess if that'll work out or not. I have solid hopes in XForms being part of Acrobat Reader, we'll have to see about that.
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.
Well I hear you, and that's why there's nothing keeping you from having your <kip:button/> in SVG. That's what RCC is for: you (or someone else) creates nifty widgets. You import them with a single element, and reuse them directly. It's one step removed from just using XUL, but a step that allows you to have the exact widgets you want to have. The following article is the first out of three and as a primer doesn't go very deep into the matters of the fact, but I recommend reading it (and especially reading the two following articles that'll have some nice demos). Some of you will recognise the author (and know that he does have SGV widget-sets ready for use :).
SVG and XForms: A primer, by Antoine Quint http://www-106.ibm.com/developerworks/xml/library/x-svgxf1.html
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.
Yes, Macromedia supporting SVG is rather nice :)
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.
Well, I can't prove the numbers, but I can prove that I've done it and that it worked out really well (customers still happy with it two years later, and still hacking on it here and there). Also, the number of GIS applications that use SVG as their interface is visible in the number of people talking about them on various lists. The feedback from SVG Open 2003 was that they were asking for a few extra features, but overall really loved it (add pinch of salt since it was an SVG conference).
There are many SVG implementations, and yes you can try the new 1.2 stuff in Adobe's implementation (free as in beer). I hear from the kSVG folks that they'll have the interesting parts of 1.2 in soonish as well (for the free in as sex part). The 1.0 and 1.1 stuff that's been used to date is testable as well.
Oh, and looking hard I can't find any bald spot in my own hair ;)
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.
Of SVG+XForms, no, since integration between those two is an ongoing project (but looking good, there is some stuff). Of either of those technologies there's a fair amount. The XForms test suite is rather bland, but scratches the surface of what XForms can do. I've ported their calculator to SVG+XForms, but I still need to wait for the next release of SVG implementations to do it better.
There's a bunch of SVG RCC components starting to happen as seen on svg-dev. Antoine will have a number of them available as part of his follow-up articles on IBM, watch that space.
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.
I find XUL a bit limiting in that it is a concrete syntax for UI. That's nice up to a point, but when you want to start making some weird-ass widget (a good example from SVG Open was a magnifier that you can drag over points of your app and acts and looks like a real magnifier, with distortion on the edges and all) you need access to the lower level stuff.
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.
Yes, network access is vital. I'm working on an IRC client in SVG, more news when I'm done :)
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.
For the forms stuff, stealing from Cocoon and looking into that server-side implementation of XForms (that converts to HTML+script) from IBM would imho be interesting steps. For the WS part, I think that making U-shaped pipelines easier to set up and use would do most of the job (to allow others to build stuff more easily). I think we can do without support for SOAP/RPC (which most big cos are giving up on anyway) and focus on supporting document/literal SOAP, which fits our idea of a document much better IMHO.
-- Robin Berjon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
