LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
flarn2006

Change XNode development to use an INI key rather than a license, and open the XNode development forum to the public

Status: Declined

NI is not encouraging development of XNodes at this time.

Usually, unsupported LabVIEW features can be enabled with nothing more than an undocumented INI key. The one exception that I know of is the integrated XNode development feature in the Windows version, which is instead controlled by the license manager. (This feature exists in the Linux and Mac versions as well, but on those versions it's an INI key like everything else.)

 

Despite not being officially supported, community-made XNodes are very much a thing. Even on the Windows version, one can still create them using a third-party editor, or hack their way into the built-in one somehow. And it's clear that NI (rightfully) doesn't put much if any continued effort into preventing third parties from making XNodes, as the same methods that were used over a decade ago still work just as well now.

 

I'm not asking NI to provide official support for XNodes necessarily, but I think it's for the best if they at least remove all unnecessary, artificial roadblocks, and open up the XNode development forum and perhaps some internal documentation to the public, so community-based developers can at least have the best shot at learning how to do it right. You've already done this with Project Providers; why not XNodes as well?

2 Comments
AristosQueue (NI)
NI Employee (retired)

What makes project providers different from XNodes?

Providers affect how the code gets written; XNodes affect what code is written, and that has been shown to be perilous.

 

Someone writes a project provider that doesn't work? User uninstalls and keeps working. Someone writes a useful-seeming XNode that doesn't quite work, and it derails entire application? User may not even know the source of the crash, and it could be causing problems on their user's system further downstream. The risk-reward calculation for the two features is very different, with XNodes having some steep risks that just don't make it worth our time to open that door further.

 

Above, I'm speaking for R&D. Below, I'm speaking purely for myself:

I would rather users rally around productizing XNodes. than around changing the licensing for unreleased feature. The original idea for this was shot down rather early: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/xnode/idi-p/1946887

Perhaps a new idea would gain more traction?

 

I wish we could get the bandwidth to stabilize and productize XNodes, but until that longshot project gets approved, I don't trust XNodes that I myself write without being able to inspect the C++ code and be sure that their doing the transforms that I think they're doing at ever stage. Even when they appear to work in G, sometimes they have weird side effects that are frankly mind boggling -- shortcuts taken in their implementation mean that sometimes the invariants that LV relies upon behind the scenes aren't maintained. Therefore, I think the general population risk is worth maintaining the high bar to entry.

Christina_R
Active Participant
Status changed to: Declined

NI is not encouraging development of XNodes at this time.


Christina Rogers
Principal Product Owner, LabVIEW R&D