[
Lists Home |
Date Index |
Thread Index
]
>
> >What we have here is a failure to communicate. I'm out.
>
> Please don't be like that. I enjoyed lurking the browser thread discussion
> very much. I went wrong when people (Whoever) tried to explain that massive
> apps could not be carried by a browser interface. Although the thread went
> from the lack of support of modern (read:XML) technologies in IE to browser
> use in Enterprise size Apps, it has still allot of relevance. But let's
> indeed talk about user interfaces and not (for example) Transact-SQL, the
> two are simply a few tiers too far away from each other.
>
> I think the point Len tried to make is (&& If Wrong = True Then Correct(Me))
> that browsers can cupport some ... but not the whole of an Enterprise app.
> What is the answer then ? Thin-Client ? Part desktop app and part browser ?
> And when ?
From my observation, Len's post entirely missed Paul's point, which
was cheekily made having mostly missed Len's earlier point. Oh well. C'est
la guerre.
The way I see it, and, I think, Paul, is that browsers are most obviously the
thin client, a convenient user interface toolkit. But if you scratch the
surface a bit, you see that they are much more. Browsers in well-designed
apps become, in effect, a powerful component cataloging system (Paul's point
about URL-addressing). Believe me, OO and Relational titans have been
wrestling for decades now just to get as useful a component catalog as the
simple Browser/URL model.*
In Len's scenario, the difficulties seem to have nothing to do with UI nor
with component interaction. To me the main problem seems to be that he might
better have been using more of a multi-dimensional DBMS (say Pick), than an
RDBMS. But choice of database model is an argument for another day. The
point
I've yet to see refuted is that the browser is highly relevant in modern
development as part thin-client UI, part focus for component organization.
A secondary matter of interest to me: the notion Len brought up of XDocs as
the foundation of some new way to package all the power of the Web into each
app without all the problems. I see nothing in any description of XDocs so
far that even hints at such a prospect. So is there some information I'm
missing? Why is XDoc different from any other authoring toolkit with hooks
for template-driven processing? I never heard such toolkits heralded as the
next wonder in application development.
Maybe MSThralldom comes with rose-tinted glasses?
* This thought is inspired by, but entirely parenthetical to this thread: I
think that the whole Web services versus REST brouhaha centers can be seen in
terms of the understanding of the browser's power as a component integration
framework. The classic Web services folks are largely the same people who
have been trying for ages to hammer together workable object repositories and
systems for sewing together disparate database-driven apps (and largely
failing at those tasks, frankly). They brought all their baggage to the idea
of Web services and the result was early SOAP/WSDL/etc. The RESTifarian's
point is mostly that the former group needs to learn to shed their baggage at
the door and understand that URL space as charted by browsers already provides
a lot of the framework needed for binding components effectively together.
Web services themselves can be much more light weight and practical if they
take advantage of this fact rather than ignoring it.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html
|
