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