See inline below.
On Tue, Aug 27, 2019 at 5:10 AM Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Sukchan,
thanks for sharing your thoughts.
On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:
Anyway, in order to share the code used by 4G/5G,
I will separate the
repository as follows:
[...]
In general, I think it may make sense to split things up, but only to the
extent
that the related [library] code is really going to be used by multiple
applications
which logically don't belong together.
I currently don't know sufficiently about 5G to know how much of the
existing code would be needed in a 5G core. For example, I don't think
DIAMETER is used in a true/native 5G core.
Also I don't enough knowledge of 5G Core either. I really want to remove
the freeDiameter library in 5G. But DIAMETER still needs to connect the IMS
core on 5G. If true, I need to separate freeDiameter and NextEPC.
This approach
is similar to the osmocom project. In fact, I'm not sure
whether this is good or not. However, osmocom manages 2G/3G like this
and I
believe that experience.
Beware there are consequences. For example, if you have libraries in a
separate repository, you must be very careful about maintaining ABI and
API compatibility, as well as managing LIBVERSION properly. This means
in general it's best to never modify any existing symbol (function) but
to only introduce new ones. Otherwise a library upgrade without
application upgrade would break.
Also, you typically want to ensure backwards API compatibility, so that
any old application can be build with any new library version. In order
to ensure this, it is best to have automatic testing that e.g. builds
all old/existing tags of applications against the 'master of the day'
of libraries.
So given the limited resources (time/developers), it requires careful
thinking whether all the related overhead makes sense. Some things can
be automatized, but it also requires quite a bit of discipline from the
developer[s]. So be warned :P
I missed the library compatibility part. In split repository, I agreed that
it would be really hard to manage this. Hmm..IMHO, I need to reduce the
number of library since my time and ability is limited.
Please, feel
free to give any idea the above plan. Expecially, 'NAMING'.
^^;
I think it's a good idea to avoid nextepc naming confusion related to
the U.S. entity nextepc inc. using an older codebase and your new
project.
I agree it is a good idea to separate any shared libraries into separate
repositories, but only *if* they are used by multiple other
repositories, and if you are committed to providing a rather stable API
and ABI.
I am not sure if moving towards the full set of repositories as
described is the best choice at this point. It might be an idea to only
separate those which you will need from your new 5G core elements?
by the way: When creating the new repositories, make sure the git
history remains. You can create the new repositories using 'git
filter-branch' of the current nextepc.git repository, keeping the
history of all the relevant commits. Finally, you can then rename/move
files in one new commit.
The git commit history is just as important or sometimes even more
important for any future developers than the actual
code.
I will do it definitely!
Of course the above is just my opinion. It's your project, you get to
decide :)
I'm really appreciated for your comments. From your advice, I'll revise the
REPO like the followings.
Repo1 : libogscore - apt install libogscore-dev
Repo2 : libogs-asn1c
- common : apt install libogs-asn1c-common-dev
- s1ap : apt install libogs-asn1c-s1ap-dev
Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev
- libfdcore
- libfdproto
Repo4 : Changes nextepc to ogs-epc.
Best Regards,
Sukchan
Regards,해
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)