Jack Schwartz wrote: > >>> >>>> >>>> - The "Remote Server module". From reading the document, it is not >>>> clear to me how it is going to be used. A few immediate questions >>>> that >>>> come to mind are: Is it going run as a server? Who starts the >>>> remote server module? >>> The remote server module is what the client hooks into to retrieve >>> data. I called it a server as it serves data to the client. >>> Clients (e.g. finalizer scripts) would run a program which calls >>> into this module to retrieve data from the primary server. >> I think that's the idea that I am confused about. Why we need a >> remote server module? Why not make the primary >> server module be able to handle remote request as well? > The primary server module *does* handle remote requests but there > needs to be a mechanism to get the request to it and to retrieve the > data from it. The remote server module packages and sends the request > to the primary server, and returns the data it gets back from it. The > client calls the remote server module to handle the request so that it > won't have to know about the underlying protocols. >> Any request of data through a socket is remote, and will >> only be read only. > If you mean the data access made available to the remote client, this > is true. (I didn't think there was a requirement for the remote > client to be able to change the tree.) > > The sockets themselves, of course, are bi-directional. >> If they want to update the tree, then, they would need the "handle" >> for the tree object. So, unless >> they have the tree object handle, they can't write the data. > Do remote clients need to update the tree? > > If they do, there is a way to implement that given the "handle" I'm > talking about, but I don't think there's a need. >> >> You mentioned that the remove server module will make a copy of the >> tree. > I didn't say that. I said that the remote server module will image > the tree, not copy it. It will present the tree to the remote process > in the sense that the remote process can access the data in the tree, > but there will be only one copy of the tree and that will be on the > server. >> How will this copy of the >> tree be kept up-to-date with the "original" tree maintained by the >> primary server module? >> If we just have 1 server, things are much simpler. > See above. > I talked to Jack in person yesterday. It looks like my confusion is his use of terminology. After we talked, I understand that the "Remote Server Module" is actually just a program with the knowledge of contacting the Primary server module to retrieve information from the the XML tree setup in memory. This "Remote Server Module" will make it easy for any consumer to get values from the XML tree because it encapsulates all the code for contacting the server..etc..
Given this information, I think that "Remote Server Module" is not a good term to use. This is because when people think of "server", they think of a process running in the background serving requests, and it won't terminate unless it is killed explicitly. Since this is not the case, the name of this program should not contain the word "server" at all. I also think that the term "remote" is not correct, since remote implies that this is not done on the same machine, while in fact it is, since the primary server will be starting on a Unix domain socket, and not a inet socket. Thanks, --Karen
