16 Dec
2008
16 Dec
'08
8:33 a.m.
On 12/16/08 15:27, Andrei Pelinescu-Onciul wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
On Dec 16, 2008 at 15:02, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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
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