Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (athena.apache.org: 212.159.14.134 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
In-reply-to: <c30d70960802040734qc09d6e9pd9e56f131270a094@mail.gmail.com> 
References: <200802041518.m14FIrGi017046@d06av04.portsmouth.uk.ibm.com>
 <c30d70960802040734qc09d6e9pd9e56f131270a094@mail.gmail.com>
Comments: In-reply-to "Alexei Fedotov" <alexei.fedotov@gmail.com>
   message dated "Mon, 04 Feb 2008 18:34:08 +0300."
From: Mark Hindess <mark.hindess@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [general] Should we make portlib a separate component? 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 04 Feb 2008 17:57:43 +0000
Message-Id: <E1JM5aL-0003qK-It@pih-relay08.plus.net>


On 4 February 2008 at 18:34, "Alexei Fedotov" <alexei.fedotov@gmail.com>
wrote:
> Hello Mark,
> Doesn't autoconf insert GPL license in the code by default, does it?

I don't think so.  Wouldn't that already be a problem if it did - since
we use apr and apr-util which both use autoconf?

Anyway, don't get hung up on that.  It was just a example in what was
intended to be a general comment about using the right tool for the job.
(autoconf might be that tool but there are other choices these days.)

> Generally modularity looks tempting.

Good.  That was my main motivation.

> I'm not yet convinced that we should generally move away from using
> APR instead of moving APR closer to what we want.

That would be a huge task and I see no sign of effort being applied to
that problem.  I'd like to be wrong though?

The portlib API is a good deal more flexible.  (Nevertheless, it might
be an interesting exercise to implement portlib on APR.)

> The synergy with another Apache project seems to be a good Apache
> practice.

I agree but I don't see anything synergistic about combining harmony
with APR.  APR is not a good fit - see discussions in the archives.

Regards,
 Mark.

> On Feb 4, 2008 6:18 PM, Mark Hindess <mark.hindess@googlemail.com> wrote:
> >
> > Should portlib be a separate component like classlib, drlvm, jdktools,
> > etc.?
> >
> > Currently portlib is closely associated with classlib.  It is built in
> > the same way as any other classlib module.  But really it isn't just
> > another classlib module.  It's a porting layer for classlib, DRLVM,
> > jdktools, etc.
> >
> > It is suppose to have a well-defined API ... but we changed the API
> > without a second thought when the patch for HARMONY-2236, for example,
> > was committed.  I'm under no illusions that having portlib as a separate
> > component will stop this happening but I think it would help us think
> > about it a little differently.
> >
> > It would also enable us to apply versioning (branching/tagging) to
> > portlib separately from classlib which in turn would allow us to
> > manage changes to the API more easily.  Classlib/DRLVM could make
> > compile/runtime decisions based on the version of the portlib API that
> > is found.
> >
> > Separate versioning of this component should make it easier to make
> > changes and extend the portlib to cover additional requirements.  For
> > example, to better support DRLVM, particularly if it moved away from
> > using APR which I seem to recall was mentioned (again) recently.
> >
> > It would also give us the flexibility to choose to have portlib use a
> > different build mechanism in future - such as autoconf - if we decided
> > that was more suitable for a pure native code component.
> >
> > Comments?
> >
> > Regards,
> >  Mark.
> -- 
> With best regards,
> Alexei,
> ESSD, Intel