On Mon, 10 Nov 2003, David W. Forslund wrote:
...
> > 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).
> >
> 1) isn't what I said I said I invoked the object and that is what I
> observe it returns. How do I tell it to return something different?
Dave,
How can the client tell the server what it likes to see? Send a request.
This is the chicken and egg problem. It can make a request that has no meaning to the server.
I believe you are describing the normal web paradigm where one logs into a system and
it presents a web page of "things" it knows about or can do and one selects them.
This is fine for a web app used by a user, but not so good if it was a distributed
application where one server is talking to another (or perhaps a 100) and wants to
do some kind of data integration.
... > SO I write client code by probing a server and seeing what it answers > with, rather than having a place where I can ask what it wants?
With Zope, you can "ask" the server what it needs to process the request.
I implemented something like that here: http://www.txoutcome.org/scripts/zope/readings/zsvg_graph_site/graph_me This method gives the required parameter list if the arguments are missing.
In any application you can introduce methods so the person can ask for what it needs.
This is a good idea, but if it is different for every application, it can be very laborious
trying to figure all of this out. In PIDS we provide methods to return the supported
traits as well as the properties of each trait. This is a standard interface and its behavior
is well known independent of a particular implementation.
Certainly this could be done in Zope, but it would be nice if it didn't depend on Zope.
It seems to me that Zope is basically equivalent to the JSP/Servlet paradigm of Java,
perhaps more elegant but functionally about the same.
> One is much more efficient than the other.
It is debatable which one is more efficient. :-)
I'm not sure what you mean. If I don't know what your servers capabilities are and I
have to make "random" queries to the server to discover what it can do, this is not
very efficient. If it followed a documented "pattern" and had a set of well-defined services,
it would relatively easy to use.
...
> > 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.
> I can write a CORBA client that completely configures itself based on
> the data types coming back. Not very "rigid".
CORBA/Java is more rigid in the way that the documentation must be produced (e.g. via IDL, type declarations).
Strong typing has its advantages and disadvantages. In the area of standard interfaces with well defined behaviors, it has a big advantage.
I can also write a Zope client that completely configures itself based on the data that come back.
> It can, in fact, discover the data type coming back rather than having > to "guess".
Same with Zope.
So the browser can discover the data type coming back and take actions based on this?
What format is the data in? XML, HTML, free text? Do you have an example?
Or are you referring to another piece of Zope code that processes the data from a Zope application?
I can believe that is the case, but that isn't in the examples of your Zope usage, which is basically
to a browser.
...
> > "legitimate" interface description language. For example, I showed an
> > HTML form as the "interface description" for adding a sub-folder into the
> > OIO Library. :-)
> >
> Is this a standard way that is available for any Zope object?
Any Zope object can have an associated web-form.
My question still is "is this 'standard'?" or is this just an optional capability of Zope. In your
examples the Zope server tells the browser what its capabilities are through a web-form. For
Zope talking to Zope, I wouldn't think this would be the most desirable way of doing this. Can a Zope
server know that it is talking to a Zope client? It still seems that the primary usage of Zope is
server to client (just like JSP/Servlets or even ASP for that matter).
...
> > That's not true. You can embed processing instructions (even Java code) in
> > the response.
> How do I know it is Java code?
Annotate the code block with a java tag?
This is a piece of the answer to the question I keep asking. What is the semantics
used to let a client know what the server is returning or capable of? How is it expressed?
In XML tags? If so, what are the "standard" tags. Sounds like this is one of them.
...
> > 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.
> >
> Perhaps, but I don't need that to make a DNS or LDAP call. I understand
> the semantics and ack on them
There exists some semantics that remain to be defined. Communication requires the ability to transmit novel concepts based on new semantics.
What is the definition of a "novel concept". How is a system supposed to know
that it is a "novel concept" that perhaps it hasn't seen before and how is it to
act on it? Otherwise, the result is not what I would call "computable". I have
to go ask someone what is going on to figure out how to process the data. This
is the same state that HL7 is in today. To get my HL7 system to "understand"
the HL7 from a given hospital system, I have to get their 100 page document and
read it and the modify my system to conform to its custom behavior. This leads
to lots of one-time-use software being written and adds substantially to the cost
of healthcare IT today. We should be able to negotiate the semantics of
our communication fully electronically. That is why standards are very important,
including standards that don't depend on the implementation of a system.
... > > I disagree. HTML happens to be a nice standard that the Mozilla web > > browser renders adequately. > > > But HTML doesn't tell me what any of these things "are".
These things "are" to be displayed as tables, cells, paragraphs, etc. Send the right request to the right place and you may get the right response. How is that any different in CORBA/Java?
The items you referred to have meaning far beyond how they are displayed. They
have relationships and meaning in the healthcare enterprise that surposs the simple
issue of how they are displayed. You seem to be talking about Zope in this context
of displaying data for a user and interacting with it. This I fully understand, but it is
a long way from a distributed computing environment.
... > > No, send anything you like - send an XML document between Zope servers. > > How do I know what the meaning of the terms in the XML are without > having some external standard?
But we do have external standards. All XML tags rely on accepted written human language.
But if I use a tag <Stuff> how are you to interpret it? Stuff may mean something
completely different to you than to me. You then take my <Stuff> tag and process
in a totally meaningless way. This is why we need standard descriptions of data and
functions, so that when I get a <Stuff> tag, I know what it "means". This all
should work independent of programming language and service implementation.
I don't doubt that Zope can do all of this, but people keep creating their own personal
dialects for information that doesn't allow systems to work together regardless of how they
are written. You may not like CORBA, but it does enable this. WebServices can do something
similar, but the corresponding standards haven't been developed yet, and I'm not sure people
seem all that interested in developing or even mapping them from earlier standards. Everyone
seems to want to do their own thing. And we continue to have chaos.
Sorry for the long response, but my issues are not really with Zope, but with the approach that
many people have that "their" way is best and everyone should conform to their model. We need
a flexible model that can adapt to a variety of situations and whose behavior can be discovered.
Thanks,
Dave
Best regards,
Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
