"Geir Magnusson Jr." wrote:
> Sam Ruby wrote:
> >
> > Geir Magnusson Jr. wrote:
> > >
> > > Call it 'Rupert'.
> >
> > Be careful, that name might stick. ;-)
>
> That would be fine - forward progress! I guess the logo would be
> next... :)
>
> > > I mean, with Tomcat 4, nothing really guarantees that you
> > > won't abandon Servlet 2.3 for the Wiggly Green Spec from
> > > Planet Mongo, but I trust that you will stick to your
> > > 'mission'... :)
> >
> > The are *SOME* things that the PMC are ready, willing, and able to enforce
> > immediately. You just happened to pick one of them.
>
> Really? How's that? If all the developers decided to switch to the
> WGSfromPM, what could the PMC do? I am not trying to be argumentative -
> I just thought that the PMC was well described as 'general oversight'
> with project-specific issues pushed down to the project participants.
>
IMHO, the PMC would certainly behave as Sam indicated, but they probably
wouldn't have to -- the ASF Board would undoubtedly say such a thing would be so
far out of scope that it wouldn't be "Tomcat" any more.
>
> If the tomcat developers, arguably some of the top-tier servlet
> infrastructure developers in the world, decided that the WGSfromPM was
> superior to Servlet 2.3 ? Granted, Craig would be looking for a new
> employer, I think... :)
>
Yah, especially if WGSfromPM == .NET's APIs or something like that :-)
>
> > Not to mention the fact that the likehood of a majority of Tomcat
> > developers would be predisposed to consider such a thing is basically nil.
>
> And back to the issue, that is kinda my point : if you have a group of
> developers committed to producing a top quality db connection pool for
> general use, it's not clear that there is much one could do to enforce
> API stability in an external way that makes sense. At some point, you
> have to trust someone involved with the project...
>
My personal preferences in this regard are fairly simple -- publish APIs (or use
existing ones where there are reasonable standards) that you promise reasonably
stable contracts for, and innovate on the implementation(s) inside those APIs.
When changes ultimately do occur, they should be designed to minimize the pain
of adapting (through techniques like providing convenience base classes that
most alternative implementations would have started from).
For a connection pool in particular, the relavant API (for my needs, at least)
is javax.sql.DataSource -- I want to be able to plug in *any* connection pool
that conforms to that interface and use it. Turbine's pool (still) does not do
this -- and that makes perfect sense, because it existed before the DataSource
API was standardized. Changing Turbine's pool to conform to this would break
the contracts for all existing Turbine apps that use it, which would not be a
Good Thing.
But in the mean time, without a wrapper around it -- I'm about 75% done with
this, but unfortunately the wrapper will have to be bigger than the entire code
for the Struts connection pool :-( -- the Turbine connection pool is not useful
to me. Whether it is in a shared repository or not makes no difference.
>
> geir
>
> >
> > - Sam Ruby
> >
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
