[Openframeworkwg] Googleable names
bgoldiez at ist.ucf.edu
Thu Jan 30 10:47:36 PST 2014
Please delete me from this list.
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
> 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
>> 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.
> Openframeworkwg mailing list
> Openframeworkwg at lists.openfabrics.org
More information about the ofiwg