Will new releases of Slice Master and DX Labs be compatible with 2.3.9?

  • 1
  • Question
  • Updated 5 months ago
Given the API changes will new releases of Slice Master and DX Labs still be compatible with SSDR 2.3.9?

I hope the answer is yes as I use both along with CW Skimmer and do not anticipate upgrading SSDR for the foreseeable future.

Otherwise I'll have to stay with the older SM and DX Labs and skip any new functions. that may be introduced

Photo of Pat N6PAT

Pat N6PAT

  • 797 Posts
  • 259 Reply Likes

Posted 5 months ago

  • 1
Photo of Bill -VA3WTB

Bill -VA3WTB

  • 3888 Posts
  • 947 Reply Likes
Won't the versions we have now for V2 still not keep working, hope so.
Photo of Mike, W8BE

Mike, W8BE

  • 172 Posts
  • 38 Reply Likes
Pat,

I have DX labs and have not issues on 2.4.9 or 3.0.19.  I don't recall seeing any updates on the application before I upgraded SmartSDR.  

Mike
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
Donald confirmed Slice Master will be upgraded to support V3 in the near term.
Photo of Pat N6PAT

Pat N6PAT

  • 797 Posts
  • 259 Reply Likes
I know that. What I'm asking is if the new versions of SM and DX LABS will be backward compatible with SSDR 2.3.9
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
I can't speak for Donald but the current version works with V2 and whatever new version would work with V3.

This is up to the developers for these respective applications on how they plan to package their applications... Nothing to do with Flex.

Developers may choose to maintain two versions or roll Flex V2/V3 compatibility into a single app.
(Edited)
Photo of Dave AA6YQ

Dave AA6YQ

  • 197 Posts
  • 227 Reply Likes
"Nothing to do with Flex"?

Right, it was the tooth fairy that made v3 non-upward-compatible with v2.

My plan for DXLab's Commander component is to have one version that supports v2 and v3, but the latter will not initially support multiFlex. Whether it will ever support multiFlex is tbd, based on feedback from the DXLab user community.
Photo of Pat N6PAT

Pat N6PAT

  • 797 Posts
  • 259 Reply Likes
I'm not sure that Dwayne understands the issue with the Flex API change.

Dwayne, Flex made changes to the API that make some third party packages incompatible with V3. This means that the third party developers have to do a lot of work for their software to function with V3

My question was will the applications still function with 2.3.9 as well. I wanted to know this because like many other ops I will not be upgrading to V3

Dave and Don have answered my question

Thanks guys.
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
I believe I understand given I spend a significant amount of time buried in code writing to various API's. By definition, API stands for Application Programming Interface and an API provides a means for third parties to interface with an application.

Ideally API's are backward compatible but sometimes there are very good reasons why an API needs to change. Depending on whether an API is a high level API vs a low level API the changes can be significant.

For a low level API, it could be related to 32bit code vs 64bit code, single threaded vs multi threaded operations, or taking advantage of new processor capabilities such as DPDK on Intel processors. For high level API's it may be the conversion from how the API is access such SOAP to REST, or data presentation such as XML to JSON. 

The applications I support in my day job just went though similar conversions and they will continue to do so as the applications and API's themselves evolve. Our API updates are normally linked to major version changes such as V2 to V3. Ideally strategic 3rd party developers are involved with betas and can release updates to their programs at the same time as the vendor, but in my day job its common for there to be a lag of anywhere from 1-6 months as non strategic vendors commit resources to update their applications.  Some vendors may choose to abandon support.

Flex has a published API for V3. For likely good reasons as I have explained above, the API changed from V2 to V3. Now we just need to wait for third parties to update their apps. How the respective vendors do that is up to them... Whether they maintain API compatibility for V2 and V3 in the same application, or maintain two independent releases for each version of SDR is up to the third party.

For ops that have workflows that are not V3 compatible, its a simple choice... Stay with V2 until the app is updated, or find an alternative app if the V3 features are so compelling you need to change.

You talk about waiting for V4... I would expect the API to change again... which would be totally normal and expected for a major version change. Every Windows and Mac OS update throws some apps for a loop.
(Edited)
Photo of Pat N6PAT

Pat N6PAT

  • 797 Posts
  • 259 Reply Likes
I'm not "waiting" for V4. I just said I may not upgrade till V4, or 5, or 6.

V4 may not have anything useful to me to justify $199. Who knows when I'll upgrade again.
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
I apologize for not being clearer... The same delay in 3rd party application compatibility you are frustrated with in V3 will likely be present in future major versions... V4, V5, or V6 based on how the radio evolves, how Windows evolves, or how the 3rd parties consume the API.
(Edited)
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
"Nothing to do with Flex"?
Right, it was the tooth fairy that made v3 non-upward-compatible with v2.
How 3rd parties consume the API (only to the spec or custom hacks), and package their Applications (one app for all versions or a unique app for each version) is up to the 3rd party application developer. This is what I meant by nothing to do with Flex. 

I'm in the process of confirming but ideally, the new API would be backward compatible so the latest/current API would support older software. 
 
(Edited)
Photo of K1DBO

K1DBO

  • 542 Posts
  • 112 Reply Likes
Official Response
Pat,

My plan for Slice Master is to support v2 along with v3 all in a single release. I've barely started the work to support v3 but at this point I believe I can make good on the plan.  

--Don

Photo of Pat N6PAT

Pat N6PAT

  • 797 Posts
  • 259 Reply Likes
Don,

Thanks for the info. I use SM all the time along with CW Skimmer and DX Labs. It really is impressive how they all work together so well

I won't be upgrading SSDR till at least V4 or later depending on what features are included.
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
You realize V4 which has not even been announced is likely 18-24 months out at the very least.
Since you are not upgrading why did you even need to ask the question given your current software works?
Photo of Pat N6PAT

Pat N6PAT

  • 797 Posts
  • 259 Reply Likes
I thought it was very clear.

I am staying with SSDR 2.3.9 .  Flex changed their API.

Third party developers are changing their software to work with the new API..When the third party developers release new versions that work with the new Flex API will future versions with new features work with the existing SSDR 2.3.9.

In other words will it be backwards compatible? If not then I would not be able to use the new releases of the third party packages.

I know there has been no mention of V4 but I have no interest in V3 at all so V4 would be the earliest I would upgrade assuming there is something I want to upgrade for. Who knows, I might not upgrade until V5, 6, 7...That all depends on Flex and what they include in each new version.
Photo of Dwayne - NA6US

Dwayne - NA6US

  • 85 Posts
  • 14 Reply Likes
Got it. As a developer myself, it comes down to the difficulty in maintaining two API's and how many users are using say V2 vs V3. It's really up to the individual developer/app.
Photo of Dave - WB5NHL

Dave - WB5NHL

  • 285 Posts
  • 64 Reply Likes
As with most software issues it appears the alternatives for 3rd party programs is not simple. In another post to the Flexradio io group it was pointed out that there are really 2 API implementations.
1. The TCP API that can provide backward compatibility but appears to put a greater burden on the 3rd party software and perhaps less flexibility.
2. The Flex lib API implementation that provides more programming resources (and perhaps simpler) but has evolved from v2 to v3 and isn't backward compatible.
Not a simple choice for 3rd party support.

Photo of Dave AA6YQ

Dave AA6YQ

  • 197 Posts
  • 227 Reply Likes

Most 3rd party apps chose between the TCP API and FlexLib at a time when it was assumed that future versions of SmartSDR would maintain an upward-compatible API. I suspect that fewer developers would have chosen the FlexLib path had they understood that it would in the future require developing and maintaining two versions of their applications.

Hopefully Flex management will eliminate this dichotomy in future versions of SmartSDR, and never again introduce new incompatibilities.
Photo of Dave - WB5NHL

Dave - WB5NHL

  • 285 Posts
  • 64 Reply Likes
For years we heard about the Flex open API as a positive feature of Flex radios. Perhaps at this years Flex banquet we can hear the rationale for the Flex lib approach and what to expect going forward.
Photo of Dave AA6YQ

Dave AA6YQ

  • 197 Posts
  • 227 Reply Likes
Providing an API and recruiting 3rd party developers to build an ecosystem of complementary applications can generate huge benefits for both the company and the user community. For the company, it expands the total available market, creates new evangelists, and strengthens the brand. For users, it expands available functionality, and provides alternatives from which the "best fit" can be chosen. The cost -- defining, documenting, and maintaining the API -- should be modest.

A poorly managed API, however, becomes a nightmare for everyone. Unhappy 3rd party developers grumble or abandon ship, and spread negative messages to the market. Users are left without applications to which they've grown accustomed, intensifying the negative market vibe. Repairing a broken API-based ecosystem is ~10X harder than the original assembly - an expensive task for the company, particularly with respect to resource diversion.

One hopes Flex Management will choose wisely.
(Edited)

This conversation is no longer open for comments or replies.