[nanomsg] Re: nn_symbol on steroids
- From: Evan Wies <evan@xxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 04 Dec 2013 13:26:37 -0500
Paul,
I was the original committer of the nn_symbol code. You can find some
original discussion here [1].
Overall, I think namespacing makes sense. And if a user just wants the
constant names, they can ignore it. As you can see here [2], I
currently use the "^E" pattern to separate out Error codes in the LuaJIT
binding, but couldn't do more without something like your proposal:
nn_symbol was originally made as simple as possible to facilitate the
language binding, so that should be a consideration. The new API is
fine for the binding I maintain (LuaJIT), but I'm not sure about the others.
Of course your change breaks ABI/API and existing bindings.
The namespace symbols themselves should be added, e.g.:
{ NN_NS_NAMESPACE, "NN_NS_NAMESPACE", NN_NS_NAMESPACE, NN_TYPE_NONE },
{ NN_NS_VERSION, "NN_NS_VERSION", NN_NS_NAMESPACE, NN_TYPE_NONE },
....
I don't have an opinion about semantic types in general, but I could see
why it would be cool for something like nanoconfig.
Regards,
Evan
[1] //www.freelists.org/post/nanomsg/RFC-Error-code-query-API
[2]
https://github.com/nanomsg/luajit-nanomsg/blob/master/nanomsg-ffi.lua#L64
On 11/25/2013 12:33 PM, Paul Colomiets wrote:
Hi,
I've just created a pull request [1] for the nn_symbol, how I would
like it to be. Basically its:
int nn_symbol (int i, struct nn_symbol_properties *buf, int buflen);
With structure being:
struct nn_symbol_properties {
/* The constant value */
int value;
/* The contant name */
const char* name;
/* The constant namespace, or zero for namespaces themselves */
int ns;
/* The option type for socket option constants */
int type;
};
So basically it adds few things:
1. Namespace, so you may turn number into name without clashes [2]
2. Socket option type, so language bindings can have fool-proof setsockopt
3. Extensibility, if we ever want to add some more info we don't loose
ABI compatibility
The questions for everybody are:
1. It it ok?
2. Any migration path needed at this stage?
3. How to treat a type. The experimental commit has two types
NN_TYPE_INT and NN_TYPE_STR. I would add more semantic types:
* NN_TYPE_MILLISECONDS
* NN_TYPE_BYTES
* NN_TYPE_STRING_LIST (subscribe/unsubscribe)
Thoughts?
[1]: https://github.com/nanomsg/nanomsg/pull/200
[2]: https://github.com/nanomsg/nanomsg/issues/161
Other related posts:
