Joe Bohn wrote:
I agree with Jeremy. One other aspect to consider is that technology
is constantly changing. If we settle on terminology today that isn't
confusing for either tomcat or jetty that doesn't mean that it won't
cause confusion for container X in the future. We will never be able
to pick terms that are generic for all time, all containers, all
components. I think attempting to come up with some common terminology
will also be confusing to the user and will make it difficult to explain
concepts that are similar or very different between containers.
If we do end up with some common mapping, then I think we need to pick
the most obvious terminology for the user.
Bingo. Lets pick the appropriate term now. Its 1 single term that is
in question here. This should be a simple resolution and does not need
endless debate. The Tomcat integration, in particular, the connector
has had many terms changed for Geronimo. Only 1 causes confusion. Why
is this an issue to change this one term? It is explained more clearly
below why I think this need changing.
Most users will consider
"host" to be the IP host name and so I think we should use that term in
general and cover the appropriate mapping to tomcat or jetty in
documentation.
Sorry, but I think this is an opinionated statement without any merit.
It's a simple fact that the host is mapped to an ip address, not the
address itself.
Per Webopeodia: http://www.webopedia.com/TERM/h/host.html
"A computer that is connected to a TCP/IP network, including the
Internet. Each host has a unique IP address."
Per The Telecom Glossary: http://www.atis.org/tg2k/_host_address.html it
states...
The definition of host is "A fully qualified domain name (usually
alphabetic) identifying the address of one specific host computer on the
Internet."
So I do not agree with your statement that 'Most users will consider
"host" to be the IP.' You are also alienating those who use Tomcat that
their definition of a "host" coincides with your opinion, which again,
is simply incorrect.
The user will have to coordinate settings between many
different elements and using common terms will make that much easier
than avoiding those terms because they bring specific meaning to some
particular component.
Geronimo is a conglomeration of different technologies. I see no
problem with trying our best to carry out the best in naming conventions
and not cross define/name terms. Now is the time to use best-practice
naming conventions. Again, I do not see why this is a problem,
especially at a point that its feasible to change. I must point out
that "host" is what is in question...and this will be terribly confusing
with how a Host is utilized in a Tomcat configuration. We need to be
sensitive to this for those users coming to use Geronimo from Tomcat.
This may help clarify...
o.a.t.Host - The Host object...the attribute "name" is the DNS resolved
name of the host.
o.a.t.Engine - contains a defaultHost paramater that is mandatory. The
defaultHost *must* match a DNS Host named object.
o.a.t.Connector - has a parameter named "address". This is mapped to
the physical or logical *IP ADDRESS* to which to listen on for handling
requests. It is not a host.
Geronimo connector wants to use "host" for the address. Understand that
the connectors are configured in the j2ee-server-plan.xml file (or
tomcat-conig.xml in the source code). Understand the confusion this
will cause when Tomcat is using the word "host" or a subset of the word
"host" in its configuration, and the the connector definition of a host
is completely different.
Why is this an issue that we cannot use a generic term such as "address"
or "inetaddress" or anything else that does not use the term "host"?
Understand the implication of this.
Joe
Jeremy Boynes wrote:
Aaron Mulder wrote:
I disagree -- I think it's important to have a common management
interface (currently, for example, NetworkConnector), and having the
same properties called something different in every networkable GBean
totally defeats that.
I agree a common management interface is desirable. Unfortunately the
containers we are integrating appear to have little in common. From
what I hear Jeff saying, apparently simple concepts like "host" differ.
What this means is that we will need substantial extensions to the
"common" interface to deal with these container specific concepts; the
lowest common denominator is proving to be too low.
This does mean more work for us: alternative deployment
infrastructure, alternative management APIs, multiple management
portlets, and so on. However, it provides a simple and more intuitive
interface for the user so should be done.
--
Jeremy
