External USSD interface development

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Kurtis Heimerl kheimerl at cs.washington.edu
Sun Jan 14 06:16:21 UTC 2018


Hi Vadim, Harald,

I wanted to speak up and second the need to fix the USSD system, as Vadim
notes it's actually just broken at the moment and doesn't meet the
standard. A student in my lab (Rowan, cc'd) recently had to extend it to be
able to interface with ussd_airflow, I believe building off of earlier
fairwaves patches. We'd also like to be able to upstream those fixes to the
community, but it seems that Harald's legacy support issue is the big
hangup? Wouldn't it be easier to put related library versions into the
changelog or something similar? Git submodules for instance allow you to
specify a specific submodule hash and a mechanism like that could free up
the interface development.

Just some thoughts. Thanks to everyone for bringing this issue up.

On Sat, Jan 13, 2018 at 3:00 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Vadim,
>
> I'm sorry to respond to your elaborate mail in a very short way:
>
> We do not want to break building old versions of OsmoNITB & Co
> with new library versions.  Every time we do this, we are creating
> problems to our users.   We have done this several times in the
> past, and it's always a pain to handle.
>
> Let's assume anyone wants to build an old OsmoNITB version, for example
> in order to test for a regression (e.g. using 'git bisect').  How
> would you do this, if for every version you want to test, you need
> also *all* the matching libosmo* of that time.  To make things worse,
> you don't even know which of the versions you need to use, making
> it impossible to hunt down when a regression was introduced in an effective
> way.
>
> It would be really nice to have some automatic jenkins build jobs that
> actually test at least building old code (e.g. openbsc.git) against
> current 'master' libraries to avoid accidents, and to even clean up some
> of the incompatibilities we may have introduced since, if possible.
>
> It's bad enough if we break this by accident.  It's much worse if we
> do it knowingly.
>
> So whatever we do, we have to try our best to keep old APIs stable
> or backwards-compatible.  In most cases, the old API would simply
> be a compatibility wrapper around the new API.  So there's one
> implementation of a given functionality, but the new users use it
> directly, while the old users go through a compatibility wrapper.
>
> I don't have the details of the USSD code in my head, but I'd be surprised
> if it wouldn't be possible to simply wrap the new API behind an old
> API compat wrapper?  If you encounter any specific problems, feel
> free to discuss ways how we can do this.
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180113/2c471b9b/attachment.htm>


More information about the OpenBSC mailing list