[
Lists Home |
Date Index |
Thread Index
]
On Friday, October 18, 2002, at 07:59 PM, Paul Prescod wrote:
> Agreed! In fact, even well-architected desktop apps have a clear
> separation of concerns between the user interface, the control logic
> and the data. Today, it makes increasing sense to express that
> separation using XML over sockets (rather than putting SQL in the UI).
>
And this is better how? You swap one linear syntax over sockets for
another linear syntax over sockets and this is supposed to make it
elegant because its <genuflect>XML</genuflect>? These two approaches
are fundamentally the same thing.
>
> My hypothesis is that rich, browser based GUI interfaces are
> inevitable.
Yes I agree with this.
> Based on dHTML, XUL, dSVG, HTML, java, .NET? I can't predict yet.
> These days I'm experimenting with dynamic SVG. I'd love to see XUL
> standardized.
No, none of these are enough (well, maybe java, only the current
implementations aren't up to it). These only specify *appearances* not
behavior. We want to get behavior into the UI layer. No more
elaborate syntax is going to solve this problem. The problem as I see
it is that XML is a retrograde development in computer science and
application architecture.
In the early software days the emphasis was on behavior (C, Fortran,
Pascal, procedures, functions) and data was secondary. Presently the
emphasis appears to be data formats (and serial ones at that).
Somewhere in between was a balanced approach that bound behavior with
data into entities we called "objects". It is my opinion that
browsers need to move from glorified page layout engines with ugly
scripting languages towards full blown distributed object engines that
happen to have rich page layout capabilities.
Let us not forget that the browser was designed to share documents.
Application delivery was a secondary concern and its definitely a force
fit. The paradigm is wrong and switching from HTML to ZZML isn't going
to change that.
I don't hold out any hope at all from the Java people or the .NET
people - neither one has a grasp of what flexible objects look like
(the compiler type checking semantics in their languages and VMs are
unforgiving and brittle). The best approach I've seeing is from the
WebObjects people at Apple and that is falling flat due to limitations
in the client layer - either Java Swing applications or HTML in
browsers.
We need a completely new client geared towards distributed
applications. Possibly one of the Smalltalks - they're already
incredibly portable and provide flexible object engines.
Unfortunately, none of their custodians have the focus to build them
out in this fashion.
Todd Blanchard
Systems Architect.
|
