Hello,
I couldn't get the message with a final decision regarding the library naming scheme. Andrei used libsr_xyz at some point, I also like this one. Henning committed directly lib/trie in his branch.
I will look soon to make the library out of mi, thinking of: libsr_kmi or libsr_mi, depending or not whether we want to mark the origin.
So, two things to decide: - do we stick to libsr_ as prefix to all new libraries included in srouter? - do we want to mark the origin of the library? Short term, might be good as pattern to know what is required for k version of the module. This can be fixed with good documentation. Long term the name might look strange.
Cheers, Daniel
On Dec 16, 2008 at 15:02, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I couldn't get the message with a final decision regarding the library naming scheme. Andrei used libsr_xyz at some point, I also like this one. Henning committed directly lib/trie in his branch.
It looks like most people prefer libsrxyz (without '_'). At least everybody agreed with libsrdb1 and libsrdb2.
I will look soon to make the library out of mi, thinking of: libsr_kmi or libsr_mi, depending or not whether we want to mark the origin.
So, two things to decide:
- do we stick to libsr_ as prefix to all new libraries included in srouter?
- do we want to mark the origin of the library? Short term, might be
good as pattern to know what is required for k version of the module.
IMHO we should mark the origin if there are 2 different versions or if the lib is transitional (will be obsoleted). If there is only one version which we will keep (e.g. trie) we don't need to.
As far as mi is concerned, I hope is one of the things that will be obsoleted in future versions. IMHO is too closely modeled on xmlrpc, and is far too complex compared with ser rpcs and more difficult to write. It's true it supports structs inside structs, but I don't think anybody needs nested structs in a management or rpc interface.
Andrei P.S.: the vim git:file plugin is great, e.g.: vim origin/henning/trie:lib/trie/Makefile
On 12/16/08 15:27, Andrei Pelinescu-Onciul wrote:
On Dec 16, 2008 at 15:02, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I couldn't get the message with a final decision regarding the library naming scheme. Andrei used libsr_xyz at some point, I also like this one. Henning committed directly lib/trie in his branch.
It looks like most people prefer libsrxyz (without '_'). At least everybody agreed with libsrdb1 and libsrdb2.
ok, and for sub-directories in lib/, should use srxyz? I am not sure now someone will use these libs for development of other applications outside the srouter source tree. Do you have in ser now "*-dev" packaging?
Daniel
I will look soon to make the library out of mi, thinking of: libsr_kmi or libsr_mi, depending or not whether we want to mark the origin.
So, two things to decide:
- do we stick to libsr_ as prefix to all new libraries included in srouter?
- do we want to mark the origin of the library? Short term, might be
good as pattern to know what is required for k version of the module.
IMHO we should mark the origin if there are 2 different versions or if the lib is transitional (will be obsoleted). If there is only one version which we will keep (e.g. trie) we don't need to.
As far as mi is concerned, I hope is one of the things that will be obsoleted in future versions. IMHO is too closely modeled on xmlrpc, and is far too complex compared with ser rpcs and more difficult to write. It's true it supports structs inside structs, but I don't think anybody needs nested structs in a management or rpc interface.
Andrei P.S.: the vim git:file plugin is great, e.g.: vim origin/henning/trie:lib/trie/Makefile
On Dec 16, 2008 at 15:33, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/16/08 15:27, Andrei Pelinescu-Onciul wrote:
On Dec 16, 2008 at 15:02, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I couldn't get the message with a final decision regarding the library naming scheme. Andrei used libsr_xyz at some point, I also like this one. Henning committed directly lib/trie in his branch.
It looks like most people prefer libsrxyz (without '_'). At least everybody agreed with libsrdb1 and libsrdb2.
ok, and for sub-directories in lib/, should use srxyz? I am not sure now someone will use these libs for development of other applications
In general they can't be used outside sr, unless you are very carefully not to depend on anything from the core (e.g. mallocs). I don't see any advantage in using either srxyz or xyz, so I don't think we should enforce it. Do we vote or toss a coin? :-)
outside the srouter source tree. Do you have in ser now "*-dev" packaging?
No.
Andrei
On 12/16/08 15:46, Andrei Pelinescu-Onciul wrote:
On Dec 16, 2008 at 15:33, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/16/08 15:27, Andrei Pelinescu-Onciul wrote:
On Dec 16, 2008 at 15:02, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I couldn't get the message with a final decision regarding the library naming scheme. Andrei used libsr_xyz at some point, I also like this one. Henning committed directly lib/trie in his branch.
It looks like most people prefer libsrxyz (without '_'). At least everybody agreed with libsrdb1 and libsrdb2.
ok, and for sub-directories in lib/, should use srxyz? I am not sure now someone will use these libs for development of other applications
In general they can't be used outside sr, unless you are very carefully not to depend on anything from the core (e.g. mallocs). I don't see any advantage in using either srxyz or xyz, so I don't think we should enforce it. Do we vote or toss a coin? :-)
one for all, or each for himself? In the first case we have to vote who toss the coin :-) ...
we can leave it xyz now, future needs will be solved as they come.
Thanks, Daniel
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla