On Thu, Jul 13, 2006 at 11:03:27AM -0400, Tom Lane wrote:
> The only argument I find interesting for including the PLs in core
> (which has zilch to do with how any particular packager ships them)
> is that it's easier to do maintenance that way: if we make a change in
> an API that affects the PLs, we can change the PLs at the same time.
> However, that argument only holds water if the core developers are
> able/willing to make the corresponding changes. And in that light,
> the fact that PL/Java includes a huge whack of non-C code is very
> significant. *I* won't take responsibility for fixing PL/Java when
> I break it, because I don't know Java well enough. I don't know what
> other people who do core development feel about that --- but I dislike
> the idea that when someone changes such an API, the buildfarm will go
> all red because there's only one person with the ability to fix PL/Java.
Tom:
Currently, the PL implementations combine both language-specific glue
and language-specific abstractions together. In light of your comments
below, and the opinion I expressed in my previous response, I find
myself wondering whether this architecture is contributing to the
problem.
Would it make sense for this architecture to be split?
My thinking is that much of the code in the Perl, TCL, Java, ... PL
implementations is related to language-specific abstractions and
documentation, and does not need to be bundled with the core, nor
does it need to be tested as a part of the core. For example, I imagine
that many of the lines in PL/Java could be distributed as a single
hardware-independent .jar file separate from the core, if the core
exposed the required API to Java.
Where this could go, is that the core developers would only be
responsible for ensuring that the backend API functions as documented,
without needing to understand how these functions are exposed to the
user. You agree to maintain Java interfaces to the C functions. No more,
no less. If somebody else wants to build complicated abstractions on top,
or wants to provide thousands of pages of documentation - this is their
choice, but would be distributed separate from the core, but would be
simple to plug in.
Am I just spitting crazy talk, or is this making sense?
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
