[DotGNU]Re: Network SEE architecture, v2.0.1

[Stephen Compall]

Hi Chris. Before starting, I'd just like to point everyone to some 
history: I asked about the VRS & SEE projects connectedness, and here is 
Bill Lance's reply 
<http://www.dotgnu.org/pipermail/developers/2002-February/006020.html>

The following month, he changed his mind, a little bit: 
<http://www.dotgnu.org/pipermail/developers/2002-March/006340.html>

Also, I don't know much more about VRS implementation plans yet, so take 
all my assumptions about the VRS arch with a grain of salt.

Chris Smith wrote:
> > http://csserver.evansville.edu/~sc87/see-arch.txt
>
> I can't get it out of my head that the SEE and VRS are very similar beasts:
>
>                               SEE      VRS
> ...
> Supports the addition of       Y        Y
> new protocols/transports

Well, handling new protocols is really somewhat up to the webservice 
writer. But the transports are handled. i.e., I consider that if you 
just take a blob of XML, and wrap it in a SOAP envelope, SOAP is a 
transport in this case, because seeuser can create the envelope and 
seeport can strip it.

> Requires identification        Y        Y

It requires identification of the server, but not the client. Right now. 
Crazy huh? ;) Maybe if the auth people define their interoperable 
protocol, I can drop seeauth in.

> How someone adds 'echo servers' to the VRS and requests access to webservices 
> stored in the VRS has not been identified.

Well, echo server is just an example ;)

> From what I've read in your SEE document it looks like you've identified all 
> the important bits.  In terms of protocol/transport the VRS is modular with a 
> well defined internal messaging API.  Adding a Jabber transport mechanism is 

I don't know exactly what you mean by "well-defined internal messaging 
API." The plan with see*port and see*user, as well as seeauth when it 
comes along someday, is that anyone who wants to implement in a lang 
other than C++ will just have to write a convenience wrapper around 
his/her favorite XML library for that platform. Also ability to 
open/close files and create FIFOs would be good. [Systems that don't 
have FIFOs, and I don't think any of those exist anymore, will have some 
kind of "Virtual IPC" thing.]

The XML communications are not that complicated, here is an example of 
something that might work for passing a new connected user to a webservice:

<!-- whereas ClientID is just a seeauth ID number (remember, seeauth 
holds persistent state) -->
<Connection ID="3" ClientID="F00F00C9">
 <ReceivedData>/var/SEE/Connections/~sc87/echo.3.in</ReceivedData>
 <Output>/var/SEE/Connections/~sc87/echo.3.out</Output>
</Connection>

So there is really no need for a complicated system. I just invented 
this off the top of my head, and it seems to cover all the bases. In 
that sense, the IPC is well-defined. It's not well-defined like CORBA, 
though. But I don't know which you mean.

> as straightforward as writing something that listens for and understands 
> Jabber messages and can inject them into the VRS in the internal format. Easy.
>
> You also need an equivalent that takes the resultant message coming out of 
> the VRS and fires it back as Jabber.
>
> The equivalent in the SEE are seeport and seeuser.

Actually, what you have described is solely see*port functionality, if I 
read you correctly. see*user is best thought of as an IPC-based 
transport library. I use it instead of libraries because IPC is more 
portable across languages.

Furthermore, a SEE-compliant webservice PE stub takes two filenames on 
the commandline -- whether or not this happens is to be determined by 
the seeRLSuser -- much as how the service daemon takes two filenames in 
XML. It connects to these, and that's it. To both sides, it feels like 
direct communication, except using FIFOs instead of network sockets. e.g.

stub <-> FIFOs <-> seeHTTPuser <-> network <-> seeHTTPport <-> FIFOs <-> 
service daemon

I have patched the informal spec to this effect.

There is also an important difference between the SEE and VRS: to 
operate correctly, the SEE must be installed on both client and server 
machines. Not all the see*ports and see*users need run, but the SEE must 
be there.

However, this is not true of VRS, at least as far as I can gather from 
the name. A Virtual Remote Server should, IMHO, look just like a 
regular, single-machine service to the user. Maybe more machines hosting 
it though ;)

--
Stephen Compall
Formerly known as S11001001
DotGNU `Contributor' -- http://dotgnu.org

When I cook spaghetti, I do object if someone else eats it, because
then I cannot eat it. His action hurts me exactly as much as it
benefits him; only one of us can eat the spaghetti, so the question
is, which? The smallest distinction between us is enough to tip the
ethical balance.

But whether you run or change a program I wrote affects you directly
and me only indirectly. Whether you give a copy to your friend affects
you and your friend much more than it affects me. I shouldn't have the
power to tell you not to do these things. No one should.
        -- RMS, "Why Software Should Not Have Owners"