Re: [ptp-dev] Attributes

["Randy M. Roberts" <rsqrd@xxxxxxxx>]

Nathan,

The way you describe your desire for how attributes work is precisely
what I was aiming for in the views that I created in ptp.rm.core
and ptp.rm.ui, which have been committed, but are currently unused.

There are no fixed attributes in ptp.rm.core, you instead ask for an
array of "self-documenting" attributes from elements.  The attribute
is responsible for returning an attribute description that contains
a short name, for table columns, and a longer description for mousing-
over.

I would like to integrate these into PTP at some time.  I currently
have that on the back burner compared to ripping out ORTE, etc. into
their own plug-ins.

Regards,
Randy

On Thu, 2006-06-08 at 08:33 -0600, Nathan DeBardeleben wrote:
> I intend to change the way attributes are used in our system (not the 
> implementation *of* the attributes, just how they're used).  I believe 
> Randy's committed (or committing) some new Attribute code so I wanted to 
> see how we can fit together on this.
> 
> Currently the UI (I think it's just the UI code) assumes certain 
> attributes are there at all times.  It assumes for a node we know the 
> node number, the owner of the node, the state, etc.  Some attributes 
> probably need to be required (node number, process ID) but many others 
> might not (node temperature, node owner (many systems have no concept of 
> this)).  As such, I was thinking the runtime subsystem should send back 
> attributes as a tuple of the [DISPLAY_NAME, ATTRIBUTE_VALUE].  An 
> example would be ["Process Identifier",12345] and ["Node Temperature", 
> "100 degrees F"] and ["Node Number", 64]
> 
> Since some of the code uses things like the PID (I can think of the 
> debugger, mainly) we would need some way to define that hardcoded.
> I would suggest a define somewhere (static public constant string, 
> whatever :)) like this:
> static public constant string PID = "Process Identifier";
> Then we could change the string internally if we needed , but the 
> debugger (and other similar tools) would always have this there.
> 
> The UI would have to become a bit more robust.  If new attributes were 
> there, it would need to display them.  If none were there (see last 
> email) it would have to be able to handle that.
> 
> Imagine a system where upon startup the runtime subsystem has sent us 
> back info about each node - Node Number, Node State, Node Owner (in 
> bproc system), Node Group (again, bproc).  So we've got these 4 attribs, 
> and the UI is showing them accordingly.  Then, suppose, there is a 
> temperature monitor on the system that  only reports when the node gets 
> sufficiently hot.  This occurs and the runtime system sends up a new 
> attribute - ["Node Temperature", "120 degrees F"].  I would want the 
> attribute and UI infrastructure to handle this, add the attribute in, 
> and just display the new stuff accordingly.  Further suppose there's a 
> plugin on the Eclipse side that looks for this.  It would need to be 
> coded in such a way that it can handle it not being there (such as 
> before this event occurred) but then when it sees it, wham, it wakes up 
> and does something magical.
> 
> In truth, most of the attribute system works like this - well, perhaps 
> 50% like this.
> 
> First I want to know from Randy how this fits in with his "new 
> attributes".  Then I wanted just general feedback about this approach.
> 
> Thoughts?
> 
> I've been designing most of this out using a snapshot from Monday, so 
> once I get some feedback I'll try and integrate it with what Randy's 
> committed (or is about to commit) and see if I can work out the 
> subsequent major breakage that will occur.
>