<div dir="ltr"><div>Hi Harald,<br><br>> As re-licensing is approved by all authors meahwile, a sub-library<br>> inside libosmocore.git seems the solution.<br><br>Thanks for you assistance!<br><br>> I would assume most projects would be interested in the coding of one<br>> specific technology, and not all of them at the same time.  Yes, there<br>> might be exceptions as a multi-RAT signal analyzer, but that could then<br>> very easily link several libraries.<br>> <br>> So my preference would be to have a '2g' specific library, and reflect<br>> that in the name by using either '2g' or 'gsm' as part of the name.<br><br>Ok, this is reasonable opinion and I am agree with you. There is only one<br>possible variant in my mind - 'libosmogsm-coding'. What about this one?<br><br>As soon as we reach an agreement in this question, I will update the<br>lastest change and, I hope, my changes will be merged. Also, I would<br>like to ask anyone to check the change, because this is first time I<br>am adding a new library :)<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>With best regards,<br></div><div>Vadim Yanitskiy.<br></div></div></div></div></div></div>
<br><div class="gmail_quote">2016-09-26 11:05 GMT+07:00 Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vadim,<br>
<br>
sorry for the late foll-wup.<br>
<span class=""><br>
On Mon, Sep 12, 2016 at 10:56:11PM +0600, Vadim Yanitskiy wrote:<br>
> > I think there's one option that I would prefer: Having a new library<br>
><br>
> Ok, one may be a separate library in separate repo, or may be included<br>
> into libosmocore as a sub-library, if re-licensing would be successful.<br>
> Let's go this way.<br>
<br>
</span>As re-licensing is approved by all authors meahwile, a sub-library<br>
inside libosmocore.git seems the solution.<br>
<span class=""><br>
> > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which contains<br>
> > the gsm0503 code and has dependencies to libosmocore and libosmocodec.<br>
><br>
> IMHO, 'phy' may sound a little bit confusing. I would prefer something<br>
> like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because<br>
> there are GPRS and EDGE too.<br>
<br>
</span>I wanted the 'gsm' to indicate 2G.  Most people speak of "GSM" when they<br>
actually mean GSM+GPRS+EGPRS, i.e. second-generation technologies.<br>
<span class=""><br>
> Also, this may be a potential place for other transcoding things,<br>
> unrelated to GSM at all. We are talking about channel coging, right?<br>
> :)<br>
<br>
</span>I would assume most projects would be interested in the coding of one<br>
specific technology, and not all of them at the same time.  Yes, there<br>
might be exceptions as a multi-RAT signal analyzer, but that could then<br>
very easily link several libraries.<br>
<br>
So my preference would be to have a '2g' specific library, and reflect<br>
that in the name by using either '2g' or 'gsm' as part of the name.<br>
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
        Harald<br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
==============================<wbr>==============================<wbr>================<br>
"Privacy in residential applications is a desirable marketing option."<br>
                                                  (ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br></div></div>