Gary wrote: > Well now this is an interesting concept. If I catch your drift, you are > proposing that we use a web server to process the xml, and then > dyanamically generate the web page and send that to the browser. > Considering my distate for the development tools available to access the > DOM from the web client, I could go for that. It does seem a _little_ > odd that we use xml to communicate between the client (gtk, web > _server_, and nli) if we go by this method. So... Right, I think the front should just be a web server front that communicates with the middle. I _think_ Jeff also agrees with this. This way, you can use any language you want to talk with the middle (by sockets or corba), get the xml from the middle, and do whatever you want with it. Then you can use anything in the bag o' web master tricks to serve up nifty web pages. Gary wrote: > So do you then propose to pass xml through corba, or to just drop xml > for client/middleware communication? If we go corba, i really don't see > the point of using xml. If we use corba, I was still thinking of using the same interface (ie. send data, return data) and not a really complicated interface (ie. a special interface for connecting loci, a special interface for adding loci, etc...). Then we will still need to have some way to communicate structured information back and forth, and I think xml is good for this, since we can then use the tools built for xml, and not have to define our own language and parsers (which is what they do in the microscope example I keep talking about). > Why not? I don't really know enough about corba to argue convincingly for it now, so I think Jeff is right, we should start with the simple, and see what happens from there. Brad