[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]DotGNU task list

From: Bill Lance
Subject: Re: [DotGNU]DotGNU task list
Date: Sun, 3 Feb 2002 06:50:16 -0800 (PST)

--- Rhys Weatherley <address@hidden> wrote:
> I'm still lagging in e-mail, but catching up ...
> Bill Lance wrote:
> > Agreed, browsers are document oriented.  But does
> any
> > other application interface exist, even in
> concept?
> E-mail clients, word processors, spreadsheets, and
> pretty much any application that allows the user to
> enter
> serious data do not follow the browser model.

Sorry Rhys,
My question was poorly stated.  Of course, specific
application interfaces exist.  And the browser limited
to http methods is very clunky. [Believe me, I know. 
I do this e-mail on Yahoo with a browser.  :( ]
The browser is both a creature and a cornerstone of
the Web, but not necessarily of the Net.  I'll answer
my own question.  Yes, there is another model, and a
highly successful one.  That is the downloadable
client model of MMRPG's.  Any player of Ultima Online,
or Everquest is quite familar with it, it works quite
well, and it's self maintaining.  The downside, of
course, is the flip side of specialization.  That
client becomes intimately tied to a particular service
and server.  I am certain that this is exactly what
Microsoft sees as their strategic target, an OS as
tied to MS and these game clients are to their homes. 
XP is the first step in that direction.

As you pointed out, this also is the idea behind Java.
 A specialized client could be downloaded and run on
demand.  It also could be updated and modified as
required.  But that initial download and setup set is
a barrier, and apparently a significant one, for the
'casual user'.

The games get past this because their content is
compelling enought that people gladly pay a
subscription, and they 'EXPECT' to get something to
load. (Also, by the way, these games are probably the
most financially sucessful WebService yet to develop.)

> The browser is a terrible UI, suitable only for
> clearly
> defined tasks with little user input.  But it is
> ubiquitous
> now and so we are bascially stuck with it. 

For a lot of the things thought of as WebServices,
your absolutly right. However, it's not by accedent,
but by definition.  I think we are dealing with the
effect of the very broad definition of 'WebServices'
that we hashed through some time ago.  The MapQuest
example, as it exists today, depends on the
functionality of the browser.  Even a great deal of
'component WebServcies' design today, both SOAP and
RPC-XML, are protocols designed to ride on http.  Once
again, there's an a prior assumption that the browser
is the enduser interface.  Sort of a chicken and the
egg problem, isn't it  :)

(I know very little about the other player here now,
J2EE.  What kind of transmission protocols does it

There is actually a third model before us as well, the
'plug-in' architecture developed by Netscape to extend
the limits of http methods, and the somewhat related
DirectX extensions to IE.  RealAudio and Flash were
sucessful with this approach for some time.  But MS is
now attacking that by pulling plugin support and
demanding that we only play with their toys and no
body elses.

Pnet gives us hope for what Java should have been. 
But we are all going to have to think real hard about
these user interface problems in order to bring it to
a computer screen near you.

Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]