proposal Should OpenG Move to vi.lib?

[jgcode]

Yer, I like to ask all the big questions...

The question was raised here (among other things, but I want to focus on installation directory only) and elsewhere on whether OpenG would be better suited in vi.lib as per the NI requirements for

developing third-party APIs etc...

Why is OpenG installed to user.lib? That's simple, it's a historical thing.

Now due to changes, notably NI opening up vi.lib, things have changed.

It also turns out user.lib is so 8.0's (ha! get it?) and vi.lib is now the preferred and more professional approach for installation of third-party APIs.

I tested this in LabVIEW 2009.

It seems LabVIEW handles the transition quite well, so I think this is doable.

You can test it yourself by doing the following:

• Create a Test.vi
  
• Link Test.vi to (any) reuse VI in user.lib
  
• Save and close Test.vi
  
• Move the user.lib reuse VI to the same level in vi.lib (do not edit any folder or file names)
  
• Open Test.vi and watch LabVIEW link to the moved reuse VI
  

I have even played with changing folder names and LabVIEW is able to link to the correct VI.

So we could even review if we wanted to change _OpenG.lib to _OpenG or OpenG as per the NI recommendations for Company Name.

So what would a change like this mean? I envisage the following for OpenG Developers and End Users:

• On opening a project with OpenG, the OpenG VIs will be missing, LabVIEW will conduct a search and automatically find the new VIs in vi.lib quickly and with no user interaction
  
• All OpenG packages will have external dependencies upgraded to be the latest OpenG packages (so all linkages are correct for that package)
  
• This update of OpenG Libraries will be atomic i.e. available to the public all at the same time (as per 4.x release)
  

Thoughts?

[Val Brown]

This all sounds like a very good plan.

[jgcode]

  On 8/29/2011 at 5:28 AM, Val Brown said:

This all sounds like a very good plan.

Thanks for the support Val.

[Black Pearl]

Does it also relink as painless if you need to revert to an older OpenG-set residing in user.lib? I guess so, but I don't kown the internals how that automagic relinking takes place.

What about the rare situation someone has installed an older version manually (copy&paste) instead of using VIPM? Then we could have an old vi with the same name in user.lib. Do we get a preference on vi.lib or does it happen (even if randomly) that we get a link back to user.lib?

Had to many relinking troubles in my life...

Felix

[jgcode]

The way I see it, if it was done - the End User should install all the latest packages so the entire Library is in vi.lib (which would be in the current version e.g. LabVIEW 2009).

As for manually installing the code, I don't know, OpenG is designed to be installed using VIPM, if someone is doing some custom install I don't think we can handle all those use cases - I guess the End User would have to do what's necessary to maintain the installation then.

In terms of your example above, I would not recommend having two versions of any code installed under <LabVIEW> just for the possibility of linking to the wrong code. VIPM only allows one version of the code to be installed e.g. A v1 or A v2 - assuming of course that in your workflow you would never create two separate package streams (e.g. A v1 and B v1) with code of the same names etc..

[Olivier Jourdan]

Hey JG, related to the question of location in the LabVIEW hierarchy I guess that you need to think about the palette location. National Instruments ask us to move our toolkits from custom SAPHIR palette to existing category (i.e Connectivity, Data communication...) for future LV2012 Compatible for LabVIEW program. Other possible place could be Add-ons palette if you want to keep VIs in OpenG palette.

Olivier

[jgcode]

  On 8/30/2011 at 7:22 AM, Olivier Jourdan said:

Hey JG, related to the question of location in the LabVIEW hierarchy I guess that you need to think about the palette location. National Instruments ask us to move our toolkits from custom SAPHIR palette to existing category (i.e Connectivity, Data communication...) for future LV2012 Compatible for LabVIEW program. Other possible place could be Add-ons palette if you want to keep VIs in OpenG palette.

Olivier

Hi Olivier

Thanks for the hot tip - can you go into details about these changes for 2012?

I will head over to that NI Group also and see what I can find out.

At the moment VIPM handles generation of Top Level Menus using the Custom Category feature, so any changes to NI protocols I assume will be reflected in VIPM.

The good thing is, palette and disk hierarchy are not always related, which is the case with OpenG, so palette location would not affect a move to vi.lib (as long as everything is configured to point to the new location etc... of course).

[Olivier Jourdan]

  On 8/30/2011 at 7:49 AM, jgcode said:

At the moment VIPM handles generation of Top Level Menus using the Custom Category feature, so any changes to NI protocols I assume will be reflected in VIPM. The good thing is, palette and disk hierarchy are not always related, which is the case with OpenG, so palette location would not affect a move to vi.lib (as long as everything is configured to point to the new location etc... of course).

I agree, it's not a technical issue, but it could be philosophic debate or more simple a big change in our usual day to day OpenG usage

[Jim Kring]

Hi All,

I'm very friendly to moving OpenG into vi.lib in order to conform with NI's new standards for add-ons (and I don't see any obvious show stoppers). There are various reasons to do this (in terms of how LabVIEW gives vi.lib some special treatment not given to user.lib), in addition to the fact that it's a standard (which are probably the reasons for the standard). That said, we should consider all the possible negative impacts of the move to vi.lib and figure out their significance and ways to mitigate the problems. One possible negative impact I can think of is: any VIs that might have a hard-coded path to call these VIs by reference (low probability).

Regarding adding tools into the existing palette categories, this is an idea that JKI is currently (in the early stages of) discussing with NI, since it will involve the adoption of some new standards. The JKI team has some ideas that need to be put down onto (electronic) paper as a functional spec proposal. I'm just mentioning this, since I think that OpenG (and others like SAPHIR) would benefit from this, so I want you all to bug me/JKI about it later/often

[Aristos Queue]

The following is NOT my area of expertise. I am raising something that is possibly FUD -- it's something I've heard about that you should research further before deciding the "move to vi.lib" question.

I would be concerned about future versions of Windows. Vista and Winy both ratcheted up security for applications, and they encourage app authors to go well beyond the requirements. You can find Microsoft's current recommendations here: http://msdn.microsoft.com/en-us/library/aa368769%28v=vs.85%29.aspx

But they keep moving up, and finding that these are requirements one day soon isn't unreasonable. I can easily imagine Windows requiring that any app that modifies a directory created by an installer must itself be signed by the same original authority. That would mean OpenG's installer wouldn't be able to write to vi.lib unless NI signed the installer. Probably not desirable.

Now, on the flip side, NI might decide to move vi.lib out of Program Files under such a scenario. There's lots of possibilities here. So, it's not necessarily a showstopper, but I'd suggest you investigate MS' Windows 8 plans before deciding this issue.

[Jim Kring]

AQ,

Great points. Windows/OS permissions are a very important consideration.

My thoughts are that OpenG should probably follow suite with the official standard, since I believe that both NI and JKI will be working hard to solve this problem for everyone. For example, stuff that is installed by VIPM could be done so with special permissions (signature) granted by NI.

[Ton Plomp]

Side-note. If MS lock up program files (which I can understand), and NI moves vi.lib to the the user profile (or All-user profiles) They should make sure that there are seperate folders for each installation of LabVIEW.

Ton

[asbo]

  On 9/3/2011 at 8:07 PM, Ton Plomp said:

Side-note. If MS lock up program files (which I can understand), and NI moves vi.lib to the the user profile (or All-user profiles) They should make sure that there are seperate folders for each installation of LabVIEW.

Taking a look at my Public Documents folder, it appears this is already an observed practice - but a good point nonetheless.

[Cat]

Yes, please, move it. IMHO, user.lib should be for *user* developed code, not add-ons, which is what OpenG really is.

As a practical matter, it would also make my life a little easier. I develop on anywhere from 3 - 6 machines at one time. They are usually not networked, or not networked to each other. Therefore I have to manually xfer my user.lib between machines when I make any changes/updates. While I have a couple hundred functions I've developed myself over the years, about half of my user.lib is OpenG. So it gets copied back and forth along with the rest of my user.lib, doubling the transfer time. If OpenG were in the add-ons directory, I wouldn't have to touch it except when an actual update was available.

[Val Brown]

  On 9/6/2011 at 12:09 PM, Cat said:

Yes, please, move it. IMHO, user.lib should be for *user* developed code, not add-ons, which is what OpenG really is.

...If OpenG were in the add-ons directory, I wouldn't have to touch it except when an actual update was available.

Precisely so. And then, if for some reason you (a user) did make a "local" modification to some underlying OpenG VI, you would put the modified code into user.lib, leaving the original OpenG untouched in vi.lib.

[crelf]

I'm all for doing things right, but let's look at the economy of doing this: NI is suggesting that plugins have thier code in vi.lib, but are they requiring it? What is the impact if we keep OpenG in user.lib? What are the risks of the migration - what might break, on different OSes, different versions of LabVIEW, etc? What is the time impact of moving everything over to vi.lib and testing it thoroughly on different OSes and versions of LabVIEW (keeping in mind that every minute it takes is a minute taken away from OpenG code development)? We haven't seen much new stuff come from OpenG in a long time, and I know that we're working hard (ie: mostly JGCode) to get all our ducks in a row so that we can have a good platform to grow going forward, but is this idea worth spending time on if it means pushing out new features even further?

PS: I have no philosophical issue with OpenG being in vi.lib.

[Cat]

It's been awhile since I've done a fresh install of OpenG -- does it currently have the option of installing to somewhere other than user.lib?

[Ton Plomp]

  On 9/7/2011 at 6:24 PM, Cat said:

It's been awhile since I've done a fresh install of OpenG -- does it currently have the option of installing to somewhere other than user.lib?

Nope, simply because there is no <OpenG> symbolic path in LabVIEW. So any code you develop using OpenG, can open up on any computer with OpenG installed without needing to search for the OpenG stuff. By placing OpenG code in <vi.lib> or <user.lib> we can guarantee a smooth experience for the OpenG user (that might not even know it's using OpenG libraries).

[Val Brown]

  On 9/7/2011 at 6:10 PM, crelf said:

I'm all for doing things right..

Good, then the short answer is: yes. Doing things right from the beginning (or as soon as possible for retroactive situations) ALWAYS pays off in the long run. If not then we all ought to just be jusing shifts and FGVs, typedef clusters....

[Cat]

  On 9/7/2011 at 6:45 PM, Ton Plomp said:

Nope, simply because there is no <OpenG> symbolic path in LabVIEW. So any code you develop using OpenG, can open up on any computer with OpenG installed without needing to search for the OpenG stuff. By placing OpenG code in <vi.lib> or <user.lib> we can guarantee a smooth experience for the OpenG user (that might not even know it's using OpenG libraries).

I should have asked a clearer question. Is there an option during install of OpenG that would allow me to put it in vi.lib now, or does it have to install to user.lib? Just wondering if in the short term, while those of you who decide these issues are deciding, I can go ahead and reinstall OpenG to vi.lib where it seems most logical (to me!) for it to be. My guess is the answer is still "no"...

[Tim_S]

I've had a few calls into NI tech support lately and had to send them my entire user.lib, including (and mainly because of) the OpenG libraries. Zipping up something in the vi.lib as well as the user.lib is not a big deal to me, however it may be for a more novice LabVIEW user trying to get tech support.

[Ton Plomp]

I didn't here a reason why not to move to vi.lib (except for Chris's reasoning about manpower), so I guess it's save to go for the move. However we should go package by package, is there anybody that has a dependency map of OpenG packages?

Ton

[jgcode]

  On 9/8/2011 at 5:14 PM, Ton Plomp said:

I didn't here a reason why not to move to vi.lib (except for Chris's reasoning about manpower), so I guess it's save to go for the move. However we should go package by package, is there anybody that has a dependency map of OpenG packages?

I disagree - I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

[Val Brown]

  On 9/9/2011 at 8:10 AM, jgcode said:

,,,I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

I think so too, FWIW.

[jgcode]

  On 9/8/2011 at 5:14 PM, Ton Plomp said:

...a dependency map of OpenG packages?

This is something I have played with in the past with my reuse library in LabVIEW where VIs represent packages and I link them and then use the VI Heirarchy window to view it.

If VIPM had that feature it would be really cool. But it's probably heaps of work for a little used feature.