Namespace confusion

[Daklu]

I've been using OpenG Builder for several months for distributing my reuse code to myself. All along I have been using OGB's namespace feature. A couple weeks back I was demonstrating OGB to some coworkers and the one of them raised the question, "Why not just use the .lvlib namespace feature?" Aside from the extra step of wrapping all my reuse projects in a lvlib to make use of the namespace, I didn't have a good answer. Anyone want to take a stab at comparing/contrasting the two namespace implementations?

Tangential question: Do LVOOP classes automatically generate their own namespace making OGB and lvlib namespaces unnecessary?

[Aristos Queue]

A library is a namespace. There are many types of libraries. Among these are the .lvlib file and the .lvclass file. So, yes, there is already a namespace for the VIs in the class. Now, if you want to namespace the class itself, put the class into a .lvlib.

I've never heard of the OGB system so I can't do the compare/contrast that you asked for.

[Michael Aivaliotis]

QUOTE (Daklu @ Oct 28 2008, 11:31 AM)

Anyone want to take a stab at comparing/contrasting the two namespace implementations?

The OGB performs namespacing by renaming the physical files on disk. When you wrap VI's in a library (lvlib) the filenames stay the same on disk but when they are loaded in memory they have a name prefix which prevents them from conflicting with other VI's in memory. They both do the same thing really but since the filenames on disk don't change (with the lvlib approach) then it's still possible to have a crosslink in certain situations.

QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM)

I've never heard of the OGB system so I can't do the compare/contrast that you asked for.

I can understand not being familiar with it if you have not used it but stating you've never heard of it worries me.

[Daklu]

QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM)

I've never heard of the OGB system so I can't do the compare/contrast that you asked for.

OGB = OpenG Builder. (I edited the OP for clarity--I used only the acronym the first time around.) OGB creates namespaces by appending suffixes to filenames when the code is built.

QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM)

A library is a namespace. There are many types of libraries. Among these are the .lvlib file and the .lvclass file. So, yes, there is already a namespace for the VIs in the class. Now, if you want to namespace the class itself, put the class into a .lvlib.

So if I understand the ramifications correctly all of the following are true...?

1. Assume I have a Boat class and a Car class that are independent of each other. Both classes have a Start method. I am safe using these classes within a single project since the two Start vis belong to different namespaces.

2. Assume I have one Honda class that inherits from a Car class and another Honda class that inherits from a Lawnmower class. Since the class itself isn't namespaced, I'll run into conflicts if I try to use both of these classes in a single project, regardless of whether or not they have any common vi names. (If this is true, that implies namespaces don't propagate down through a class hierarchy. i.e. Instead of Car.Honda(.Start.vi) the namespace is just Honda(.Start.vi.))

3. VI filenames are independent of the namespace that contains them, therefore VIs with different namespaces may have the same filename and I may run into occasional conflicts if I'm not careful to separate my namespaces into different directories in both source and distributed code.

Are there other namespaces outside of .lvlib, .lvclass, and (presumably) .llb files?

[crelf]

QUOTE (Michael_Aivaliotis @ Oct 28 2008, 08:11 PM)

I can understand not being familiar with it if you have not used it but stating you've never heard of it worries me.

Maybe Stephen's heard of it as the "http://wiki.openg.org/OpenG_Builder' rel='nofollow' target="_blank">OpenG Builder" and not just by it's acronym of OGB?

[John Lokanis]

QUOTE (Daklu @ Oct 28 2008, 11:31 AM)

Anyone want to take a stab at comparing/contrasting the two namespace implementations?

I use the OGB namespace feature to build .LLB files for sets of plug-in VIs. The LLB contains all the top level plug-ins and all of their sub vis, namespaced to the name of the LLB.

This way, I can call plug-ins from more than one LLB at the same time, each with different revisions of a common sub-vi and be sure that the plugin loads with the version of the sub-vi it was tested and released with.

I do not think you can do this with LVLIB files. I don't think this is what they were intended to do. A source file on disk cannot be a member of two different LVLIB files. In my case, i want to build my LLBs from the same set of source sub-vis but lock down the version I built with so I don't have conflicts when using multiple versions from my app.

It does add an extra step to my build process (first need to build the LLBs with OGB and then build an installer for the LLBs with LV).

Finally, I am not aware of a means to build an LLB from a set of files and remove the diagrams and typedefs within LV. Even if you could do this, they don't offer a way to namespace them like OGB does.

Hope that helps explain the value of OGB to your coworkers.

-John

[Darren]

QUOTE (crelf @ Oct 28 2008, 07:40 PM)

Maybe Stephen's heard of it as the "http://wiki.openg.org/OpenG_Builder' rel='nofollow' target="_blank">OpenG Builder" and not just by it's acronym of OGB?

I assume that's it...I've heard of the OpenG Builder but I would have had trouble with the "OGB" acronym just reading the initial unedited post.

-D

[Daklu]

QUOTE (jlokanis @ Oct 28 2008, 06:10 PM)

I use the OGB namespace feature to build .LLB files for sets of plug-in VIs. The LLB contains all the top level plug-ins and all of their sub vis, namespaced to the name of the LLB.

This way, I can call plug-ins from more than one LLB at the same time, each with different revisions of a common sub-vi and be sure that the plugin loads with the version of the sub-vi it was tested and released with.

I do not think you can do this with LVLIB files. I don't think this is what they were intended to do. A source file on disk cannot be a member of two different LVLIB files. In my case, i want to build my LLBs from the same set of source sub-vis but lock down the version I built with so I don't have conflicts when using multiple versions from my app.

I think I'm following you... it sounds like you are building LLBs to take a snapshot of your reuse code and by using the snapshot in your application code you avoid breaking the app with future changes to your reuse code. You avoid conflicts by giving each snapshot a unique namespace via OGB. If that's correct, couldn't the same thing be done by copying your reuse code to a different location and wrap it in a uniquely named LVLIB, since, as near as I can tell, that's essentially what you're doing with the LLB. (With the obvious difference that you're wrapping it in an LLB instead of an LVLIB.) What am I missing?

[crelf]

QUOTE (Daklu @ Oct 28 2008, 11:58 PM)

...it sounds like you are building LLBs to take a snapshot of your reuse code and by using the snapshot in your application code you avoid breaking the app with future changes to your reuse code.

If that's what you're trying to do, why wouldn't you just use http://jkisoft.com/vipm/' rel='nofollow' target="_blank">VIPM?

[Daklu]

QUOTE (crelf @ Oct 28 2008, 09:30 PM)

If that's what you're trying to do, why wouldn't you just use http://jkisoft.com/vipm/' rel='nofollow' target="_blank">VIPM?

As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

[crelf]

QUOTE (Daklu @ Oct 29 2008, 12:54 AM)

Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

That is so sad - I'm sorry to hear that your managment is like that.

[LAVA 1.0 Content]

QUOTE (Daklu @ Oct 29 2008, 02:27 AM)

Are there other namespaces outside of .lvlib, .lvclass, and (presumably) .llb files?

XControls (but namespacing is a side effect, the main target is creating a new control)

LLB files don't do namespacing, the actual VI name (as it can be called via a Open VI reference function) stays the same so you can't have to 'Start' VIs in two LLBs in the same project.

QUOTE (Daklu @ Oct 29 2008, 06:54 AM)

As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for

n

VIPM licenses is sure to raise a few eyebrows.

You don't need n only one will be enought (i assume) just for the person that is creating packages, loading packages and installing them needs no license, however you could tell your management that you have a bargain 10 licenses for the price of one.

Ton

[TobyD]

QUOTE (Ton @ Oct 28 2008, 11:34 PM)

...you could tell your management that you have a bargain 10 licenses for the price of one.

That's a great idea! I might try that one :thumbup:

[Daklu]

QUOTE

That is so sad - I'm sorry to hear that your managment is like that.

My experience is that management in most places is like that. VIPM isn't required to do the job, it just makes certain aspects of it easier; therefore it is an unnecessary expense. On top of that Labview isn't that widely used in my group...

QUOTE ( @ Oct 28 2008, 11:34 PM)

10 licenses for the price of one.

10 for 1? That I might be able to sell, but I didn't see the offer on the VIPM website.

[TobyD]

QUOTE (Daklu @ Oct 29 2008, 12:11 PM)

10 for 1? That I might be able to sell, but I didn't see the offer on the VIPM website.

The idea is that you only need one license to build packages. Then anyone who want to use the packages downloads the free version and installs them. You can tell your manager you're getting 10+ licenses because he/she doesn't know that everyone else is getting the free version :ninja:

[Aristos Queue]

QUOTE (crelf @ Oct 28 2008, 07:40 PM)

Maybe Stephen's heard of it as the "OpenG Builder" and not just by it's acronym of OGB?

Ah. Yes. That I have heard of, and even seen demos of. :-)

In another context, I might have gotten OGB as OpenG Builder, but as "OGB's namespace feature", I was searching the internet for some sort of naming scheme like Hungarian notation or somesuch.

[crelf]

QUOTE (Daklu @ Oct 29 2008, 03:11 PM)

My experience is that management in most places is like that. VIPM isn't required to do the job, it just makes certain aspects of it easier; therefore it is an unnecessary expense.

I'm not so sure - if you can show a positive ROI, there aren't many managers in the world that wouldn't be at least interested in hearing what you've got to say Your time is worth a lot more that a license of VIPM (TobyD is soooo right about the 10 for 1 model), and buying tools gets you back to doing what you're really paid for. You wouldn't try to write a replacement for Microsoft Word - you'd just pay the license fee and use. I know that's an extreme, and you need to weigh up the functionality vs cost model, but in my experience VIPM is easily justifiable. We write our own tools, and the support that's required to keep them going is costly (imagine if you left the company and someone else took your place - how much IP do you have in the process that you're carrying out that's not on paper?) Not buying tools like VIPM stops you from doing your real job, and that's what your clients are paying for - that means that you need to hire others to share the load that you're supposed to be doing, so there's more cost there. Ok, I'll get off my soapbox now.

[Jim Kring]

QUOTE (Daklu @ Oct 28 2008, 09:54 PM)

As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

Why not start with just 1 VIPM license? This will allow you (or another member of your team in a reuse librarian mode) to build VI Packages that everyone on your team can install with the free VIPM Community Edition.

This could also serve as a way to demonstrate to your team the time (i.e. money) savings that is possible using VIPM to more effectively and efficiently reuse code.

QUOTE (TobyD @ Oct 29 2008, 12:26 PM)

The idea is that you only need one license to build packages. Then anyone who want to use the packages downloads the free version and installs them. You can tell your manager you're getting 10+ licenses because he/she doesn't know that everyone else is getting the free version :ninja:

Oops, I missed this post. I agree completely