This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Fri, 24 Aug 2007, George Bosilca wrote:
> On Aug 24, 2007, at 9:50 AM, Tim Prins wrote:
> > I do not understand why a user should have to use a RTE which supports
> > every system ever imagined, and provides every possible fault-tolerant
> > feature, when all they want is a thin RTE.
> We have all the ingredients to make a this RTE layer, i.e. loadable
> modules. The approach we proposed few months ago, to load a component
> only when we know it will be needed give us a very slim RTE (once
> applied everywhere it make sense). The biggest problem I see here is
> that we will start scattering our efforts on multiple things instead
> of working together to make what we have right now the best it can be.
I'm all for focusing effort on ORTE and making it the best it can
be, but it would seem that a more formalized component-framework
interface between the MPI layer and all of ORTE could potentially
help to achieve this.
What would be ideal would be if the OpenMPI project could define
such an interface, and also provide and support a standard reference
version of ORTE which implements this functionality. This could
provide the OpenMPI project with the minimal/stable run time layer it
needs, but at the same time make it much easier for outside projects
with other requirements to experiment with enhanced versions of ORTE,
without having to worry about the impact on core OpenMPI development.
This need not splinter the effort, rather it might make it possible for
others outside the core OpenMPI development team to more effectively
contribute to and use OpenMPI and ORTE, in particular when it comes
to integration of the software into new environments.
National Radio Astronomy Observatory (NRAO)
US National Virtual Observatory (NVO)