Re: [DotGNU]DotGNU task list

[Barry Fitzgerald]

This is something I've been thinking about but have found it hard to put
into words for some time:

The term "webservices" is inherently flawed...

"webservices" gives sense that the web is being used to provide the
service.  We may know better, but the average person thinks browser when
they think "web".  Microsoft's solution: tie the browser into everything.

This is a stupid stupid way to do things.  Precisely because of what
you've illustrated below.  Also, because you inherit any issues that come
witha  big clunky crufty interface that isn't, in the end, designed to do
what you're trying to do with it.

Also, the standard definitions of webservices (which tend to limit
webservices to transmission via XML based protocols, in this case SOAP and
XML-RPC) is also lacking.  What happens when XML is replaced by the next
great thing?  Do you say "Well, that's not a webservice because it's not
XML?"  --  No, you'd have an argument and redefine the term.  This is done
entirely too much and it's for the following reason:  People tie
implementation into conceptual terms.  This is bad.  Bad. Bad. Bad.  It
means that people are standardizing on a moving target -- it's actually a
proprietary mechanism.

In any case, the term itself and it's definition are deficient.  I prefer
to call them network services in general :) -- but, if the term "web"
carries specific meaning to people, then perhaps http NetworkServices is
more correct.

The problem with focusing the definition is that it inherently destroys
any chance of deviation from the idea and generates bad practice in the
name of standardization.  Standardization is good, overstandardization is
bad. :)  In the end, the whole may come down to this:

webservice-ize the whole system by creating an XML-RPC brokering system
that can convert the brokered input into further output formats.  There
may actually be a revolution hidden somewhere in there. :)

        -Barry


On Sun, 3 Feb 2002, Bill Lance wrote:

> Date: Sun, 3 Feb 2002 06:50:16 -0800 (PST)
> From: Bill Lance <address@hidden>
> To: Rhys Weatherley <address@hidden>, address@hidden
> Subject: Re: [DotGNU]DotGNU task list
>
>
> --- 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
> use?)
>
> 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!
> http://auctions.yahoo.com
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers
>

address@hidden
SDF Public Access UNIX System - http://sdf.lonestar.org