On Fri, Feb 25, 2011 at 11:48 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > We're definitely moving into bikeshedding territory now, but one thing > Yehuda suggested: > > The pool handle (rados_pool_t, PoolHandle) has state associated with it, > including the snap to read from or snap context to write with. That's not > obvious from the name. Maybe it should be renamed rados_ioctx_t to be > more clear. Then the pool we're reading to/writing from becomes one more > piece of state associated with the handle. PoolHandle in the C++ API and pool_t in the C API map onto RadosClient::PoolCtx, which contains the aforementioned state. So if we change this in the C++ API, we should change it all the way through, and rename pool_t, RadosClient::PoolCtx, etc. Should we? I could go either way. The concept of a handle itself having properties is not really unfamiliar. After all, two different processes can open two different file descriptors referring to the same file, but one with O_RDONLY, and the other with O_WRONLY. etc. A handle to a thing is not the same as the thing itself. Colin -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
