16 Dec
2008
16 Dec
'08
8:02 a.m.
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
--
Daniel-Constantin Mierla
http://www.asipto.com
16 Dec
16 Dec
8:27 a.m.
New subject: [SR-Dev] library naming
On Dec 16, 2008 at 15:02, Daniel-Constantin Mierla <miconda(a)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
8:33 a.m.
New subject: [SR-Dev] library naming
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
8:46 a.m.
New subject: [SR-Dev] library naming
On Dec 16, 2008 at 15:33, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 12/16/08 15:27, Andrei Pelinescu-Onciul wrote:
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? :-)
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 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.
outside the srouter source tree. Do you have in ser
now "*-dev" packaging?
No.
Andrei
10:22 a.m.
New subject: [SR-Dev] library naming
On 12/16/08 15:46, Andrei Pelinescu-Onciul wrote:
On Dec 16, 2008 at 15:33, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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
--
Daniel-Constantin Mierla
http://www.asipto.com
On 12/16/08 15:27, Andrei Pelinescu-Onciul
wrote:
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? :-)
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
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.
5859
days inactive
5859
days old
4 comments
2 participants
participants (2)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla