I could possibly buy your argument Ralph if this was a one off BTL that
only Nathan (and his employer) is going to use. I am assuming though
this is a more general protocol for a vendor specific protocol. Thus it
seems that a sane naming of the BTL is within the realm of the community.
That being said, I think I would agree that Jeff should have passed this
by Nathan first before posting the RFC (which for all I know he has)
just in case there is some background that would convince Jeff that
vader is appropriate.
On 11/17/2011 9:29 AM, Ralph Castain wrote:
> Frankly, the only vote that counts is Nathan's - it's his btl, and we
> have never forcibly made someone rename their component. I would
> suggest we not set that precedent. I'm comfortable with whatever he
> decides to call it.
> On Nov 17, 2011, at 7:00 AM, TERRY DONTJE wrote:
>> Isn't there precedent with the other BTLs to name them based on the
>> messaging protocol they are supporting instead of some movie
>> character (tcp, openib, shmem, portals, ...).
>> On 11/17/2011 8:11 AM, Jeff Squyres wrote:
>>> After having to explain to someone at SC for the umpteenth time this week that the "vader" BTL uses the XPMEM transport under the covers, I'd like to put forth an appeal to rename the "vader" BTL to be "xpmem."
>>> Here's my rationale for why:
>>> 1. Although we have a history of Star Wars-related names, the "ob1" and "r2" components got their names because they're mainly algorithms that have no obvious name that describes what they do.
>>> 2. All other components that tie into some back-end system are named reflecting the back-end system (e.g., tcp, mx, portals, ...etc.). "openib" is the weakest example, but we all know that it was named way back when OFED was named "OpenIB", and the name has kinda stuck.
>>> 3. The BTL name "xpmem" follows the law of least astonishment from the user's perspective.
>>> 4. Cute names rarely seem so after 6 months.
>>> I'll even volunteer to do the work to rename it (a bunch of file moves and global search-and-replaces).
>> <Mail Attachment.gif>
>> Terry D. Dontje | Principal Software Engineer
>> Developer Tools Engineering | +1.781.442.2631
>> Oracle *- Performance Technologies*
>> 95 Network Drive, Burlington, MA 01803
>> Email terry.dontje_at_[hidden] <mailto:terry.dontje_at_[hidden]>
>> devel mailing list
>> devel_at_[hidden] <mailto:devel_at_[hidden]>
> devel mailing list
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.781.442.2631
Oracle *- Performance Technologies*
95 Network Drive, Burlington, MA 01803
Email terry.dontje_at_[hidden] <mailto:terry.dontje_at_[hidden]>