On Sun, 9 Nov 2003, David Forslund wrote: ... > Well sure, but when I make the call to the Zope object it replies in > HTML. If it replied in some other way, my browser wouldn't no what to > do with it.
Dave, Both statements above are not true: 1) Zope can send back any kind of file. 2) Web browsers know what to do with many non-HTML files (e.g. plain text, gif, jpg, etc). > Where do I find out what Zope will answer with? It is very interesting that you are so pre-occupied with having a second channel for predicting/describing the server's response. Why not just send the REQUEST to the server and see what RESPONSE comes? > The flexibility is great, but there needs to be some agreement between > the client and server as to how they will express the request and > response. That is my only point. I don't think there is any disagreement on this point. However, there are many ways to document, negotiate, and transact according to this "agreement". Perhaps CORBA and Java have a more elaborate and rigid way of doing this - but that does not mean it is more suitable or more useful for application development. Zope applications also implement interface and request/response descriptions. They are just not in the format that you consider "legitimate" interface description language. For example, I showed an HTML form as the "interface description" for adding a sub-folder into the OIO Library. :-) ... > If I make a URI request to a Zope server, it may have no idea what I'm > talking about unless we exchange some other semantic expression of the > meaning of the URIs. Yes, indeed. What would you call this? http://www.txoutcome.org/scripts/zope/library/files/browse/newfolder?syndicated=0&objectid=313&oio_library_language=english To me, it looks like the server telling the client the _semantics_ of the arguments to be submitted to add a sub-folder. > That is why one has additional standards for understanding what the > meaning of a request is. Explaining why some people enjoy defining additional standards for "understanding the request" and "understanding the understanding of the request" is topic for another discussion :-). ... > >HTTP requests and responses can be arbitrarily complex and large. > Certainly, but they are are simply name value pairs or name values list > going in and arbitrary text coming back. Only a mime type can tell me > what to do with the data coming back, That's not true. You can embed processing instructions (even Java code) in the response. > and I can have no way of knowing what to send to a server, unless it > sends me information on a previous call, which is basically how the web > client/server relationship works. Right. That's why we have "previous calls". It does not matter whether we are using CORBA, Java, Zope, PHP, or C, either the client acts on assumptions or the server needs to send info to the client on the [previous, same, or future] call. ... > I'm sure they are not, but what will my client (web browser) do with the > information if I have no idea what the format is coming back? The server told you on a previous call? :-) The server told you on the same call? :-) The server will tell you on a future call? :-) > >However, reflection in HTML is not necessary and any reflection in the > >user interface may be indirect and optional. For instance, data > >representing multiple attributes of clinicians, supplies, procedures, > >etc in a hospital can be downloaded as needed and used to inform > >complex user interactions including browser-local database queries and > >on-the-fly generation of popup lists and tables, etc. > All customized and non standard, of course. I disagree. HTML happens to be a nice standard that the Mozilla web browser renders adequately. > I can use tcp/ip directly, too. So what is the point? HTML is a good starting point. Other XML-based standards (e.g. SVG) extend what web-browsers and servers can easily communicate. These text-based, tagged "languages" are incrementally delivering what CORBA and Java hoped to achieve. At this point, it is more productive to consider why HTML/XML are more popular. Study platforms that embody philosophy and approach that are synergistic with HTML/XML (e.g. Zope). Bring those attributes to health care/ medical applications! :-) ... > I can put anything into XML, but it doesn't mean that the person on the > other end will have any idea what I'm talking about, That's where "standards" like HTML and SVG come into play. ... > When I made a call on a Zope server it gave me an answer back in some form > of HTML. That may be quite appropriate if you are requesting a web-form from a web-browser. ... > A Zope server could talk to another Zope server without using HTML, but > I still believe the resulting code would be nearly impenetrable because > everything is called the same, and I would have to wade through the > various arguments to tell what was being asked for. No, send anything you like - send an XML document between Zope servers. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
