[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 19 Sep 2002 19:46:04 -0700
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Interesting idea. But this would require a new protocol and would be
very tricky to implement with any type of security.
xml-rpc and soap require too much "hook up time" and wont work that well
in real time, since they have to have the data put into thier envelopes.
Would be kinda neat tho.
I think that if you had a middle man who took the stream and broke it
into chunks, it *might* work.
maybe i will fiddle with this for ya
Peter Minten wrote:
here is a new idea for a program called DotGNU Webshell.
Webservices are mainly designed to be used by a user through a graphical
interface. But it should also be possible to add another method of communication
to webservices. I'm thinking of an expansion to the pipe concept of unix here.
For example say you have a webservice A that is an editor. A has 2 input
streams, one for input of new text and one for input of control commands. Now
say you have webservice B that is a voice command system, B has a whole set of
output streams where any data the user wants can be send over at the users
(voice) command, in this example only 2 streams will be used. The user
configures B so that it will produce the text the user wants to add to the file
edited in A and the commands used to control A. Then the user links the 2
programs together using the graphical interface of Webshell. The user can then
use the voice control program B to work with A even though B doesn't have to be
produced to work with A.
It's important to understand the communication between the program happens in
real-time. Data arrives for A as soon as B outputs it, immediately after B
processed it's voice command, A then takes action ASAP.
This will also make it possible to use the unix philosophy of small well defined
programs. In contrast to the system MS is trying to push through where
applications communicate with eachother, the user keeps control of what happens
Of course the communication pattern will be saveable in a script file which can
be run by Webshell. Webshell could also provide other important services to the
user like job control and file system access (both local and remote). It would
have both a graphical and console frontend.
Developers mailing list