harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] Should we make portlib a separate component?
Date Mon, 04 Feb 2008 22:18:13 GMT
Tim, Mark,

I like a careful rewording about gradual movement of internal
components to a higher level.

It would be challenging goal to get some API consensus and usage
synergy among the projects, or may be smaller parts of the projects.
Some time ago I was thinking about porting library design and argued
for APR myself, but now I believe that Cygwin approach of using open
standards such as pthread API or just Linux OS calls instead of
symmetric wrapping system API calls for every platform may worth to be
considered as an interesting portlib architecture possibility,
especially with growing virtualization opportunities. This would give
us more supporters such as Android guys. <joke>Also, we may assume
that portlib gradually replaces APR when Tomcat on the top of Harmony
replaces HTTPD.</joke>

Thanks.

On Feb 4, 2008 11:35 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Mark Hindess 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.
>
> Well it isn't today.  DRLVM and jdktools do their own thing, so it
> really is just a factoring of the class library code.
>
> > 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.
>
> I don't see why this a problem.  We have control over both sides of the
> API boundary, so changing the API to suit a usecase better is fine,
> provided the implementation and its usage is changed simultaneously --
> and it was.
>
> We don't promote the portlib APIs for our end users to use.  If we did
> then of course we would have to be more careful.  Even internally, like
> the VMI, we are careful when there are internal users.
>
> > 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.
>
> I see what you are saying, but again, I'm yet to be convinced there is a
> problem being solved here.  Why not also version control the hycommon,
> hythread, etc internal APIs too?
>
> > 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?
>
> I don't have a strong objection to moving it out to a 'top level'
> component -- it just seems premature when there is no pressing need to
> do so.  If somebody declared a porting problem, or DRLVM gurus said they
> want easier access to use it then sure.  Perhaps there is a driver that
> I'm not seeing here.
>
> It sounds like it is just a move within the project, not a re-architecture.
>
> Regards,
> Tim
>



-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message