Mladen Turk wrote:
Remy Maucherat wrote:
The native component can be used by many Tomcat releases, and has been
tagged and released independently. Of course, it is often done in sync
with Tomcat to introduce new APIs, but overall it's quite similar to
mod_jk releases.
But it's not even close to the mod_jk concept.
Mod_jk is included inside native web servers, while native
is integral part of tomcat, jut like any other java connector.
The only small difference ;)
is that part of this connector happens to be written in C.
We should start treating it this way instead trying to
bail out, just because it requires some extra work for RM.
Mladen, maybe you can explain, why you don't like the idea of making
tcnative an independant released product.
Looking at it's formal qualities, it already has some properties of such
a product:
- the API between tcnative and the component using it seems stable
- When we have a problem in tcnative, we fix it there and allow TC users
to update their tcnative independently
- we tag a common version of all what's needed to build and use tcnative
- we produce source and binary packaging out of the tag
- we provided the packages in form of an independant download in the
past, binaries not from ASF servers because we didn't like to handle the
legal crypto stuff
Possible arguments against having a separate product:
- We need an RM
- Higher level of completeness needed for the downloadable stuff (mainly
docs)
- Formal procedural overhead (mainly release voting)
- Maybe more user issues, because the API might not be as stable as we wish
and maybe more arguments, I don't see at the moment.
So please let us know, what your concern is with making it a product.
If it's only "we don't need to make it a product", then yes, but it
becomes more valuable if we make it a product.
Cheers,
Mladen
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
