[Openframeworkwg] Googleable names

[Goldiez, Brian]

Please delete me from this list. 

Brian Goldiez
Sent from my iPhone

> On Jan 30, 2014, at 1:43 PM, "Doug Ledford" <dledford at redhat.com> wrote:
> 
>> 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.
> 
> <signature.asc>
> _______________________________________________
> Openframeworkwg mailing list
> Openframeworkwg at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/openframeworkwg