Hi Nick,
> Mathias solution looks indeed
more extensible, but what troubles me is that services
> and
storage elements are described by different glue schemas with different
attributes,
> so we need to have code
that is specific for each one.
Well, yes and
no, depends on how things are implemented on your side. Actually the “Field”-values
would refer to IGridResource methods like getName() or getURI(). So if you
could map the Glue elements to Grid elements (which is of course possible and is already implemented, i.e. GridGlueComputing,
GridGlueStorage and GridGlueService)
you could easily make use of these methods.
> (even if it is in one
method/class). Moreover, I am reluctant
to do a more
> complex/general implementation
for something that is not needed and
thus it will not be used.
We are aiming for a middleware
independent framework allowing third parties to easily implement other
middleware plug-ins based on g-Eclipse. If something is not needed by gLite or
GRIA (and in fact it is needed but
not yet used. So for instance the
query containers in the VO folder of a Grid project could make use of this,
too) it is not said that it is a useless feature. So when implementing on the
middleware-independent side do not limit yourself to the middlewares we are
currently supporting but think about what would be the best way of implementing
things in general.
BTW, just had a look at the info
plug-in (which is in SVN and of
course is middleware independent, right?!) and
saw a class called GriaComputing?! What is its purpose? Why is it in
eu.geclipse.info? Is it specific to GRIA? If yes it has to be in one of the
GRIA plug-ins, if no it should not be called GriaComputing!!!
Cheers, Mathias
