W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: Another approach to agent architecture [ was Re: agents .. ]

From: Nitin Borwankar <nitin@borwankar.com>
Date: Thu, 6 Apr 1995 18:02:37 -0700 (PDT)
Message-Id: <199504070102.SAA04337@nbor.borwankar.com>
To: nsb@nsb.fv.com (Nathaniel Borenstein)
Cc: www-talk@www10.w3.org, nitin@borwankar.com, safe-tcl@cs.utk.edu
In your message you, Nathaniel Borenstein, said in most eloquent fashion
 
> I'd gotten WAY behind on my mail, but I wanted to add one comment to
> Nitin's comments on this thread.
 
> Just to clarify my position:  I am not *opposed* to an intermediate
> language (agent-lingua-franca).  I am very concerned, however, about its
> design, and about the fact that the concept remains entirely unproven.  

At the outset, let me say that my arguments were and still are from the
viewpoint of a dissemination strategy for existing technology and not from a
viewpoint of research.  To explain, I am more concerned with the question -

"How do we make sure that all this great technology doesn't get lost in
the marketing noise that will very soon flood the airwaves ?" and "How can
safe-tcl survive inspite of all the proprietary efforts ?"  

*rather than*

"What is the best/safest/most mature and proven technology".

This last question, is in my opinion, not always the right question to ask
*if we are concerned about market acceptance* which I believe we all
are.  Technically superb designs and implementations have failed to 
achieve market share, and in fact it is more the rule that technically
mediocre or even flawed technology ( need I mention the M.. company ) can
garner commanding positions through massive and well directed marketing
efforts. 
 
I initiated the intermediate language ( used here in the colloquial
sense of intermediate, rather than the CS sense of lower-level )
thread only to draw attention to the fact that a large number of 
relatively non-sophisticated users will be arriving soon. If the
current safe-tcl effort doesn't take them into account, they ( the
naive users ) will, by default, settle for the warmed over offerings 
from MediocreSoft(tm), your friendly neighborhood software company 
that wants to take over the whole world.

Having a platform like MS Network will give it a means to foist very
crude active mail models on a largely unsuspecting user/programmer
population in the vein of Dos, Win3.1, Visual Basic etc. Historically,
the Unix/Internet/University/Research Lab community has ignored these
technically unsophisticated approaches assuming they will fail in the market.

And people continue to think that because they don't
understand the Internet technology/culture MicroSplat will fail. 
How naive !!!

I feel that a similar thing may happen with the enabled mail efforts
and that alot of great technology may end up being just that - great technology
but with no ensuing products.  The bottom line is - there are no
known commercial products out there that are openly using safe-tcl.
A way to piggyback onto the momentum generated by  marketing-driven efforts
of MicroSpiff (tm )
would be to position safe-tcl as the intermediate language, thus leveraging all
existing development efforts and also using proven and safe technology.

Thus any restricted technology foisted upon the world by MicroSquash(tm),
your innovative, creative, communications company, will remain restricted in
use to the MSNetwork and safe-tcl efforts need not have to twist themselves
out of shape. In addition, to access the new and exciting content on the
Internet outside MS Network, MS Network users will have to have a way to
access safe-tcl based Net hosts. Voila'  safe-tcl intermediate language
to the rescue.

Enabled-mail content will remain safe-tcl, which can be translated into
and out of at sending and receiving ends respectively.  Rather than being
the all-encompassing enabled-mail language everywhere which is a very hard
goal to achieve, why not be the *transported language* of choice ?

This positions safe-tcl as complementary to any proprietary technology
and not in opposition.  My belief is that a head-to-head language war
with Visible Balsamic (tm) will fail simply from the numbers stand
point, and then you won't get a second chance.

The real question is, does the safe-tcl community want safe-tcl to ever be
a commercially deployed technology or is it something that is preferably kept
as a research plaything.  I don't see a clear answer to that question but the
responses I have received suggest that most safe-ctl users are from the
research side of things. ( At this point I woul like to add that this
doesn't, in any way deprecate the future efforts of the Ousterhout group
- I would consider their efforts to be based on producing tcl development tools
whereas when I say "products" I mean something outside the realm of   
development per se eg end-user products that are produced by safe-tcl
developers. )

My feeling is that if the safe-tcl community wants
to survive and prosper in commercial realms, they will have to start asking
different questions - questions more directed towards disseminating and
diffusing existing technology into commercial *products* and move away
from focusing on "my language is better than yours". I would like to suggest
that the "better" language doesn't always win in the market place.

So the real question is do we want to be a market/product based technology or
do we want to do some real neat things in our spare time ?
The kind of questions we are concerned with are, in my opinion, quite
different in the two cases.


Nitin Borwankar
nitin@borwankar.com
Princpal, Borwankar R&D.


[...]
 
> --------
> Nathaniel S. Borenstein <nsb@nsb.fv.com>  
> Chief Scientist, First Virtual Holdings Incorporated
> Phone (+1 201 540-8967)  (fax 993-3032)
> PGP key: finger nsb@nsb.fv.com  (Fingerprints: call or see my business card)
>  --------------------------------------------------------------
> | When PRIVACY Is Outlawed...Only OUTLAWS Will Have Privacy!  |
> | >>> I SUPPORT THE PHIL ZIMMERMANN LEGAL DEFENSE FUND! <<<   |
> | Email: zldf@clark.net      http://www.netresponse.com/zldf  |
>  --------------------------------------------------------------
> 
Received on Thursday, 6 April 1995 21:55:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC