[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: the web client interface was RE: Two link questi

• To: "'Simon St.Laurent'" <simonstl@s...>, xml-dev@l...
• Subject: RE: the web client interface was RE: Two link questions
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Fri, 18 Jul 2003 14:00:43 -0500

That little Macromedia app for making it easier to 
update an existing web page is a good notion.

I don't disagree that one can get a lot done inside 
the browser given an efficient browser.  Custom 
clients?  Say the unrealistic notions of SVG being 
the vector language of choice for the whole interface 
come about, what would languages that are not SVG 
compatible do?  Just because something is possible 
doesn't make it light enough to be realistic.  See 
Chrome.   I don't know if implementing that in Mozilla 
works well except for basic graphics. 

As for Mozilla as the browser of choice 
for businesses, I hope the tainting problems 
turning up for Linux are addressed.  Like RSS/nEcho, this 
laissez faire 'we don't care who owns this because we 
like the guy running the project' approach will burn 
the people signing up for it, and help the very 
competitors they think they are de-opting.  The second 
word in IP is Property.

The problems of staying inside the browser for everything:

1.  Dealing with the HTML framework in situations where 
it has neglible benefits

2.  Having existing classes for other frameworks that 
would have to be moved to the server or coded in 
seriously inefficient ways inside the HTML framework. 
In other words given legacy and no or very weak 
data standards for the content, it is not a good 
idea to go browser-based exclusively.  It is still a 
good idea to use them for viewers and light transactions.

Otherwise, a Wizard in a browser is a heckuva lot 
easier to build than in most systems.  It just 
isn't always needed.   The bigger problem is item 2.

len

From: Simon St.Laurent [mailto:simonstl@s...]

On Len's question, I don't see hypertext as "the only realistic client
for the Web".  For certain, it's the cheapest client out there, and I
can't say I see much benefit to building other systems except in a
relatively small number of cases.  From my perspective, XForms takes
care of about 90% of my remaining Web-interactivity problems - though
I'm still concerned about the odds on its widespread implementation. 

If you need something else, though - build it.  For all the effort the
Curl and Flash folks have put into Rich Internet Apps, though, I don't
see much need for a generic toolkit with powers beyond the existing
Web+XForms.  Custom clients, though - sure.  Sounds good.

• Follow-Ups:
  • Re: the web client interface was RE: Two link questions
    • From: Amelia A Lewis <amyzing@t...>

• Prev by Date: (Updated) Categories of Mismatches between Producer and Consumer
• Next by Date: Re: Categories of Mismatches between Producer andConsumer?
• Previous by thread: (Updated) Categories of Mismatches between Producer and Consumer
• Next by thread: Re: the web client interface was RE: Two link questions
• Index(es):
  • Date
  • Thread