David Forslund wrote:
>>Web browsers do not send data to servers by way of HTML. They generally do >>it via HTTP or FTP or SMTP. > >Of course, but the expression of the request on those pages generated by >Zope is an HTML form. >That is what I'm talking about. It is part of the HTML specification on the >W3C.
I don't know about anything specific to Zope, but the expression of the request in HTML
could have been merely an artifiact of the way you were viewing/requesting it. The request
that is actually sent from a browser to a server has nothing to do with HTML. That is
HTTP. Furthermore, HTML is only one way of representing or initializing objects in a
browser that can initiate HTTP requests. Browser objects can communicate with servers
independent of any representation in HTML.
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. Where do I
find out what Zope will answer with? 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. It is important
that there be a semantic agreement between the two. That is why people standardize
things like HTML to be used in conjunction with the HTTP protocol. If I'm expecting
something in HTML and get an XML response, I may not know what to do with it. Likewise
if I create an arbitrary request (which is legal), my server may not know what to do with it.
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. That is why
one has additional standards for understanding what the meaning of a request is.
>>Web servers communicate with web browsers and other client agents via the >>HTTP protocol. >>HTTPS is HTTP plus SSL encryption. That communication has nothing >>specifically to do with >>HTML. HTTP can be used to communicate any kind of digital content in >>either direction. >See above.
>>HTML is a document format that includes, among other things, a >>representation of >>hyperlinks based on URL's and a representation of input forms that can be >>used to upload >>virtually any kind of data. HTML is not the only content-type handled by >>browsers. >>Plain-text, XML, JPEG, GIF, PNG, CSS, and Javascript are the most basic >>and commonly used. > >Certainly, but javascript is only used for communication within a browser,
??? This statement might be a pivotal point of misunderstanding.
Javascript can be used to establish connections to servers and to upload and download
information directly without any necessary representation in HTML. Some of the more
interesting things to download using Javascript are data objects represented in Javascript
or XML.
Well it could be used, but I'm not aware of any significant examples of this. I also know that
Javascript can be used on the server side, but I'm not aware of any common usage.
My experience has been that the JavaScript standard seems pretty loose at least
to how it is implemented in different browsers is a compatibility problem. There
is even a CORBA adapter for JavaScript, so Javascript is certainly used for a lot of things
as a fairly general programming language. But I believe its predominant use is for dealing
with client interactions within a browser.
I know that the ESRI folks have an ArcIMS interaction within a browser using Javascript
that talks directly to their map server. However, it seems fairly fragile in such an interaction.
I guess I wasn't too precise in my statement, and I apologize for that. I'm aware of all these
uses, but they don't seem to be the common usage.
>for example. Dcouments >can have almost anything in them. But this isn't what is used in the >API. Basically there >is a simple request/response in http and the various parameters are used to >convey what can be done. >The structure of the html in the page is used to marshall the various >arguments passed in an out >through the various parameters.
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,
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. Signficant
standards such as HTML XML, or whatever, are required to make sense of this arbitrary
transport mechanism. That is the point of REST.
I know very little specifically about Zope, but I would be surprised if Zope objects are
limited to generating only HTML.
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?
>>Also, Javascript can be used in a browser to send and receive data at any >>time without >>direct representation in the user interface. Furthermore, the user >>interface for browser >>based applications can be directly manipulated via Javascript without the >>use of HTML. > >Of course. That is not what I'm talking about. Javascript typically >enables one to >effectively have dynamic html. It makes things easier to manage in the >browser (hopefully).
Hmmm. We seem to be talking past each other.
Not really. I believe I understand what you are trying to say.
The user interface of a browser based application is not necessarily based on HTML. HTML
is only one component type of many. User interface elements can be generated entirely from
Javascript or from various XML document types. The user interface *is* based on browser
objects that generally are reflected in Javascript and that may have a reflection in HTML.
Certainly.
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 can use tcp/ip directly, too. So what is the point?
Data can be moved over a socket and one has to have a way to interpret what it is that is coming
over a socket. Maybe I have to look something up in a book to figure this out (which is typical
for the HL7 "standard"), but this doesn't lead to robust portable applications.
The point I am trying to make is that web applications are not "the same as html". There
is a great deal more potential depth to them than your remarks would seem to allow.
I agree. But html (and now xml) is the lingua franca by which people communicate over the web. I can put anything
through http, but it doesn't mean that the other side will have any idea of what to do with it. This is the strength and weakness of REST. (see earlier reference).
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, unless I give them a dictionary or some additional semantics (even a DTD isn't sufficient for this). I need something like
RDF or more. People use HTML for this purpose as well as other "document" or imaging formats.
When I made a call on a Zope server it gave me an answer back in some form of HTML. Same for JSP and servlets. It wouldn't
have to but then my browser interaction would likely be less than satisfying.
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.
In a language such as Python or Java (or many others), I can look up the signature to determine what is to be happening.
This brings some level of rationality to the code being used. I don't believe zope uses URI's for internal communication but
python, because of its greater clarity and compact form and ease of maintenance.
Dave
>
>Dave
>
>
>>David Forslund wrote:
>> >> > What kind of arguments do the methods take. What about security?
>> >>
>> >>Whatever can be uploaded via http, https. Security is the same - can use
>> >>username/password or PKI certificates.
>> >
>> >Basically then the client interface is the same as html, since that is the
>> >only way to send data to the server through a browser.
>>
>>---------------------------------------
>>Jim Self
>>Chief Systems Developer and Manager
>>VMTH Computer Services, UC Davis
>>(http://www.vmth.ucdavis.edu/us/jaself)
>
>
--------------------------------------- Jim Self Chief Systems Developer and Manager VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself)
