+1 for apache-geode and Apache.Geode
> On 22 Jan, 2017, at 19:08, Ernest Burghardt <eburgha...@pivotal.io> wrote:
>
> +1 for apache-geode (.dll, .so, .dylib) and Apache.Geode.dll
>
> On Sun, Jan 22, 2017 at 7:18 AM, Michael Martell <mmart...@pivotal.io>
> wrote:
>
>> +1 for apache-geode (.dll, .so, .dylib) and Apache.Geode.dll
>>
>> On Fri, Jan 20, 2017 at 7:28 PM, Jacob Barrett <jbarr...@pivotal.io>
>> wrote:
>>
>>> As I ready to drop the pull request to rename all the namespaces in C++
>> and
>>> .NET sources the next thing we need to decide on is the filename for the
>>> library.
>>>
>>> C++
>>> Current: gfcppcache
>>> gfcppcache.dll (Windows), libgfcppcache.so (*nix), libgfcppcache.dylib
>>> (macOS)
>>> Proposed: apache-geode
>>> apache-geode.dll, libapache-geode.so, libapache-geode.dylib
>>> Other libraries have embraced other styles for "branded" libraries.
>>> Camel case: libQtCode.so
>>> Underscore: libsvn_client.so, libboost_atomic-mt.so
>>> Dash: libxcb-compose, libcairo-gobject.so
>>> I prefere dash because I don't have to hit shift. ;)
>>>
>>> .NET
>>> Current: GemStone.GemFire.Cache.dll
>>> Proposed: Apache.Geode.dll
>>> There is a bit more of an established norm. It should be part of the
>>> included namespace.
>>> Other option is Apache.Geode.Client.dll but I feel like there are items
>> in
>>> the Client namespace that need to be moved into another namespace as a
>>> sibling. So in my mind it makes more sense to have it be
>> Apache.Geode.dll.
>>> It also makes it consistent with the C++ library.
>>>
>>> -Jake
>>>
>>
