[Pipet Devel] client/server communication layer

[Gary Van Domselaar]

I'm not sure if I got this entire msg, but...

Brad Wrote
> 
> 2. How about if instead of relying on the middleware server to spit 
> out XML that will eventually be good enough to travel directly into a 
> browser (whenever browsers become sufficiently XML aware enough), we 
> require the web front to process the XML that the middle returns, and 
> then serve up web pages based on this? From what little I know about 
> Zope, it seems like it would be ideally suited to this task since I 
> think it's meant for publishing "dynamic" web pages like we would need 
> for Loci. This way, the developer of the front end could choose use a 
> "real" http server (instead of us having to program an http server) 
> and could also use other web server tools like MySQL or whatever. This 
> seems like it would free up the people interested in developing the 
> web interface to be a lot more creative in generating the user 
> interface and also to use more standard web tools that we actually 
> have now.

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...


> 
> 3. If the above two points make sense, then we now have a little 
> more flexibility for communication methods between front ends and the 
> middle. In this case, I would like to propose using corba (instead of 
> the sockets used in the microscope server example that I'm looking at) 
> to communicate between the front and the middle. This will give us a 
> lot of freedom for creating a nice interface and will allow front ends 
> to be built in any language. Initially, we could have corba servers 
> publish there IORs somewhere on the bioinformatics.org server, and 
> then as we got more users, have a dedicated loci program that 
> manages/distributes these IORs.
>     I also think corba might be a little kinder to us then 
> sockets/http in terms of a learning curve.
> 
>     Again, I think that once we have corba working, the middle could 
> be extended later to use other protocols (once xml and browsers start 
> to get along better). But this would give us a way to create the web 
> interface with tools we have now.

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.

>     Does this sound like a plan? What do the web interface people 
> think of this type of arrangement? Does it make sense? (I'm not much 
> o' a web programmer myself). If you think it might be worth a try, I 
> can whip up an idl interface to start with and we can go from there...

Why not?


> 
> Brad




_______________________________________________
pipet-devel maillist  -  pipet-devel at bioinformatics.org
http://bioinformatics.org/mailman/listinfo/pipet-devel

-- 
                                  Gary Van Domselaar
                               gary at bioinformatics.org
                          http://www.bioinformatics.org/~gary
                ----------------------------------------------------
                           bioinformatics.org: The Open Lab
                            http://www.bioinformatics.org/