Re: CEPH_RBD_API: options on image create

[Jason Dillaman <dillaman@redhat.com>]

> 
> But we don't need them to match between different platforms, no? Is
> linking 64bit code with 32bit possible (supported)?
> 
> Also, for this particular (char*) case, length would actually be the
> length of the string, not the pointer length. From my example:
> 
> const char* journal_object_pool = "journal";
> r = rbd_image_options_set(opts, RBD_OPTION_JOURNAL_OBJECT_POOL,
>                           journal_object_pool, strlen(journal_object_pool) +
>                           1);
> 

My original example was a string of length 4 vs a 4-byte int, but you said you were thinking of sizeof(type) instead.  I think this style of interface is great if you need to pass any arbitrary data along, but will we ever expect to pass along anything besides a string or an (u)int(32/64)?

On the flip-side, what will the C++ interface look like?  An equivalent API would imply passing a boost::any.  While certainly future-proof, something about that doesn't sit right with me as an API.  I think I would lean more towards something like xyz_set(const std::string&), xyz_set(uint64_t), et al.

I've been witness to too many type-casting issues in the past (in fact just hit one last night within CephContext), which makes me lean more towards having the compiler be able to enforce type-correctness.

--

Jason