Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <495CFA20.7070404@apache.org>
Date: Thu, 01 Jan 2009 17:15:12 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: tcnative API stability/compatibility
References: <495CCAD0.9000605@kippdata.de>
In-Reply-To: <495CCAD0.9000605@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

Rainer Jung wrote:
> Hi,
> 
> we now have tcnative 1.1.x and trunk. What's our goal w.r.t. API stability?

My understanding was that trunk was created to introduce APR 1.3 and
that the result would be tcnative 1.2.x.

> Citing from an earlier thread:
>>> > we do have a 1.1.x branch in tcnative which is supposed to be the
>>> stable
>>> > brach.
>>
>> Ok. I thought this was still also used in 6.0. OTOH, the library should
>> be renamed so that both v1.1 and this new incompatible one could be used
>> at the same time, right ?
>>
>> R�my
> 
> We have native and Java code in tcnative. I guess we are talking here
> mainly about the Java side, i.e. the native one is the implementation,
> which is only exposed via the Java code and the Java code represents the
> API we do make public.
> 
> I expect we want the following situation:
> - new methods can be added to tcnative trunk
+1

> - old methods are not allowed to be removed either from trunk or from 1.1.x
+1 (unless they are deprecated in 1.1.x - then they can go in 1.2.x)

>   Trunk will most likely result in 1.2.x versions, and code using
> tcnative should be able to update from 1.1 to 1.2 without
> incompatibilities.
+1

 Otherwise we would already now decide, that trunk
> will become a 2.x.
>   Methods could get deprecated in trunk though.
>   Exception: There are some methods which wouldn't have worked any time
> in the past, because they refer to native functions that don't exist. I
> think it is a good cleanup to remove/rename them now in trunk and 1.1.x.
+1 (providing they truly never worked)

> Concerning the native side. What is the compatibility goal between the
> Java code and the native lib? Do we want to urge each using software to use
> 
> a) exactly the same version of native, than the version of the Java code
> b) the same minor version, but patch version greater or equal to the
> Java side
> c) the same major version and any minor/patch greater or equal ...
> 
> I guess we want a) or b), I think it's to early for c).
> 
> If we go for b) and trunk is for a 1.2.x version, we don't need to
> support loading multiple copies of the native library. So I guess, b) is
> what we should do?
b) seems like a sensible target given I don't know how much work c)
would be.

Now is probably a good time to extract the native library into a
separate component (ie move tomcat/connectors/trunk/jni/native/
to tomcat/native etc) and treat it as an external library rather than
using svn externals. ie add tcnative to the list of libs downloaded as
part of the build process.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org