> Yes, but you seem to create a lot of confusion about how and where
> you will implement support for the new APIs eventually. That, I
> believe, is one of the main reasons we have the current situation.
> You said back in November that you where going to start a revolution
> for the 2.3 stuff, as well as other features. But it never happened
> and I see hints from you about adding support for the new APIs in 3.3
> popping up now and then, without a clear indication about when and
> where.
Then let me clarify, to avoid the confusion - I don't know yet where (
probably sourceforge or from a homepage ), and I have few ideas about
"how". I said back in November that I am going to start a revolution with
the 2.3 stuff and other features - and I didn't do it because finishing
3.3 refactoring and merging the fixes from 3.2 should happen first, and
it's much higher priority.
Since November I learned a few lessons, so I'll not do a revolution - I
don't think that will give me enough freedom ( and I'll still be at the
mercy of the PMC ). So it'll be outside apache ( consistent with what I
said about minimizing my involvment with apache projects ).
About why - it's simple, because 2.3 is the next version and to have a
future we must keep up to date.
> Maybe. I'm not convinced that you can keep the same core for all
> versions of the specs (who knows what the 2.4, if it happens, will
> hold?), at least not without having to resort to pretty convoluted
> and ineffecient code. But that's besides the point right now.
Well, I'm hoping I'll be able to convince you. The idea is quite simple -
the core is modeled after abstractions found in web servers ( it's trying
to be close to a Java and OO representation of request_rec and all other
server structures - Container==dir_struct, etc). The theory is that as
long as the servlet API will be implementable on top of a web server,
the core will do the job and most modules will be reused without any
change.
For 2.3 it's quite easy, and thanks to ClassLoaders it's also easy to have
both 2.2 and 2.3 ( and 2.0, 2.4 and any other facade ) running on the same
container ( and even instance ). While most people will not care about
that ( and they don't have to - there are just some modules and
configurations ), I think this will be important in quite a few cases and
it'll make a difference.
( of course, the facade has some other inherent advantages - mostly for
performance )
> Well, within the same project it creates a lot of confusion if we
> have more than one container the same API level. Besides, the Servlet
> 2.3
> and JSP 1.2 APIs are backwards compatible, so Tomcat 4.0 by definition
> supports 2.2/1.1 as well.
And that's not confusing :-)
In any case - I discussed about facade23 just to make clear that I
indeed plan to stick around doing 3.x-related stuff ( besides bug fixes ),
and to make clear that tomcat 3.x core has a future and will be useful for
more people, even post servlet 2.2.
> Great. As have been said a few times, you can do that as a revolution
> using a different name than Tomcat within the Jakarta project.
I don't think so - the overhead of the PMC and having to deal with people
like Jon is not worth it - and BTW, as Jon mentioned "revolutions" are
still not "aproved" by the PMC, and are a subject of debate.
So I no longer think a revolution inside jakarta is the right solution.
( and the right to follow your ideas is _not_ a subject of debate - is
more of a fundamental right - if this is not welcomed in jakarta, too
bad for it )
--
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
