Another idea: pool_t -> pool_context_t, PoolHandle -> PoolContext ? C. On Fri, Feb 25, 2011 at 12:24 PM, Colin Patrick McCabe <colin.mccabe@xxxxxxxxxxxxx> wrote: > 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
