[Openframeworkwg] Googleable names

[Doug Ledford]

On 1/30/2014 12:58 PM, Paul Grun wrote:
> Look, the objective here started out as a way to increase our
> visibility on Google.
> 
> My personal opinion is much different than Doug's in a number of
> respects.

I get that a lot ;-)

>  I do not think that anything we do should be tied to the
> underlying interconnect e.g. RDMA.  I do think that the major thrust
> of what we are doing is creating a framework that supports a set of
> composable APIs that provide applications with access to a set of I/O
> services.
> 
> To me, the focus is still, and should remain, on the framework part
> of it because that is the unique thing we're doing.  To be specific,
> the key insight, at least as I see it, is that there is no single API
> to rule them all, but rather a set of composable APIs and that
> requires a framework to make it work.  That's what makes the work we
> are doing unique.

But even a framework of composable APIs is still an API itself.  This
may be a unique API with some distinctive characteristics that makes it
somewhat special, but it's still an API.

I'll also say that maybe RDMA is the wrong phrase for me to use here
(although it's the most widely recognized generic term for what I am
referring to).  RDMA has long been an umbrella for the more generic
concept of "network I/O that does not need kernel direction and instead
goes directly to the correct user space process memory space".  It has
been *implemented* via the verbs RDMA API, but even that API is only
part RDMA and part send/recv.  What I'm really referring to is the user
space process direct nature of the underlying interconnect.  So in as
much as RDMA has been overloaded to cover all of that, I was using it in
that fashion, but I could also see a more correct name (which doesn't
yet exist I don't think).

> As far as "fabrics" go, the name of our parent organization, for
> better or for worse, is the OpenFabrics Alliance.  I don't see us
> changing that.  Nor do I read that as implying that we (the OFA) are
> defining the fabrics themselves; that has never been the charter of
> the OFA.

Yes, but it does not follow that because the organization is named
OpenFabrics Alliance that then everything the organization works on must
also be named *something*fabrics*something* or
*something*open*something*.  It is entirely legitimate for the
OpenFabrics Alliance to work on whatever it determines is germane to its
goals, and IMO it is entirely sufficient for the OpenFabrics Alliance
portion of the name to carry the brand while the rest carries the
project intent.

> Our current name is OpenFramework Working Group.  Someone pointed out
> that that does not google well.  But there is a fine line to be
> walked here - let's not give ourselves a name that is so obscure that
> nobody knows how to google for us at all.  A completely unique name
> is of no use at all if no one searches for it.

On this point I agree with Jeff: the name need not be known to be good.
 It will become known as the work is done.  No one accidentally stumbles
onto OFED or OFA EWG, they get there because they know generally what
they are aiming for and they googled it to get the exact address.  This
group will have its work known in the same way and be found in the same
way.  Obscurity at the outset is not really a concern IMO.

> So I suggest we stick pretty close to home and go with OFA Framework
> Working Group - OFWG.
> 
> Any objections? -Paul

This goes right back to the original point of the entire thread: that
particular moniker is not unique and the googleability will be
compromised.  So if we are concerned about solving the googleability
issue, then this moniker fails whether we want it to or not.  If we just
want to stick with the moniker because it tickles our fancy and not
worry about googleability, then that's a valid choice too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20140130/2fc3caca/attachment.sig>