Package Name Standardisation

[Mellroth]

I really like that icon. I vote we use that as the palette category icon.

+1

/J

[Daklu]

I vote we use that as the palette category icon.

Seeing as how it's your site I believe your vote is the only one that counts.

Any thoughts on subcategorizing the palette, or just leave that up to individual developers?

[Fab]

+1 for a Lava repository.

Found the palette icon I created.

A YELLING +1 for a Lava repository!!! and I love the icon

Fab

[gb119]

I really like that icon. I vote we use that as the palette category icon.

Umm, we already are....

If you have a look at the Scripting Tools and Array XNode packages you'll find that they install a LAVAG category with Daku's icon. I've not put them under a sub palette for the LabVIEW API yet, but I've used the LAVACR sub category icons for the palette icons for each package. If someone want to show me how to make a vipm package use a sjared second level of palette below the category then I'd be happy to move everything down one level in the hierarchy:rolleyes:.

For the package names I've gone for lava_lib_<lavacr category>_<package name> - or at least that's what I'm iterating towards...

[d_laub]

For naming, I think that it'll be important to companies to maintain their brand through their package name. "JKI Right-Click Framework" or "GOOP Develoment Suite" should be the names, since the packages are not just components in a library (where such a naming convention is sensible), but an actual product name which the developer has an interest in branding and marketing. I don't imagine picking up a shiny product brochure titled " Speed Development With jgcode_rpk_ni_system_style_daqmx_controls-1.0-1".

There still needs to be a way to quickly and easily find relevant packages as the number of packages grows (as discussed above), for which I think a combination of text search and a tag cloud would work well.

[jgcode]

For naming, I think that it'll be important to companies to maintain their brand through their package name. "JKI Right-Click Framework" or "GOOP Develoment Suite" should be the names, since the packages are not just components in a library (where such a naming convention is sensible), but an actual product name which the developer has an interest in branding and marketing. I don't imagine picking up a shiny product brochure titled " Speed Development With jgcode_rpk_ni_system_style_daqmx_controls-1.0-1".

I am guessing if you are a large company you are not going to rely on a package name for the branding and marketing of your product!

I am pretty sure you would do that through other techniques i.e. go to their website, read about it, click a link to download it, (does the name matter now?), install it into VIPM.

Anyways, in VIPM 2010, the package name wouldn't necessarily appear in the List as packages now have alias' so a different name will appear (as mentioned above).

I am talking about the name of the package (which is about as informative as any executable or installer I download from the web these days).

As this thing is definitely going to grow in the future, you are going to want to avoid any name clashes.

I am not 100%, but I am also guessing this name acts as the Primary Key in the VIPM database?

(The disk structure also follows this convention in Cache and Databases)

So you are going to want to have something informative and yet unique.

The examples you present e.g. "JKI Right-Click Framework" or "GOOP Develoment Suite" makes sense because everyone in the community knows what these are already. What happens if you come across a package you don't know about?

Having standardization (whether internal, or in the community) would help someones look at a package they haven't seen before e.g. jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" and be able to parse some stuff out of the name e.g. "hey its a repackage version of some code from NI's website for System Style DAQmx Controls, it is version 1.0-1, I may check this out and fire this up into VIPM and read its description in detail - or, nah I don't no DAQmx so I don't care etc..."

I think that is helpful?

[Francois Normandin]

Personally, I would adhere to a package naming convention if it existed. That being said, best practices take time to emerge because best practices have a lot to do with how comfortable people are with a well know concept. Has there been enough water flowing under the VIPM bridge to make it obvious what the best practices are? Probably, but it doesn't mean that everybody "has to" adhere to them to build packages. I think it'd useful to have a few "examples" of how one can name a package, just for the sake of all the occasional package builders out there. Just like design patterns, there are no "one size fits all", but a few helpful recommandations might be in order to get newbies started with a decent naming practice. After all, we've all been beginners at some point and would have liked to find a forum or wiki with a lot of helpful topics... Oh wait, it exists already!

The above-mentioned idea to have a LAVAG icon in the palettes to put all the LAVA stuff is gonna have more momentum, I think, simply because it's easy to implement and doesn't mean everyone needs to follow the rule. I wouldn't put my code under a JKI palette because well, I'm no JKI! But a LAVAG palette? Yeah, I'm a LAVA for sure... so it's as good a place to put it as any other.

[Michael Aivaliotis]

Everyone of course is free to use their own company name (or given name) as a category which goes without saying. But I'm saying it anyway.

However a nice guideline would be to use the LAVA category as the main category and then you can put your branded category as a sub-palette of that if you like.

The LAVA brand means something. We have an approval process and as time goes on we will be tightening this slightly. Possibly incorporating some of the LabVIEW Tools Network requirements as they apply to us. Being able to package your stuff and get approval to put your code underneath a LAVA palette category is special and is something everyone should be trying to do. Let's all keep working on moving forward.

[jgcode]

Everyone of course is free to use their own company name (or given name) as a category which goes without saying. But I'm saying it anyway.

However a nice guideline would be to use the LAVA category as the main category and then you can put your branded category as a sub-palette of that if you like.

The LAVA brand means something. We have an approval process and as time goes on we will be tightening this slightly. Possibly incorporating some of the LabVIEW Tools Network requirements as they apply to us. Being able to package your stuff and get approval to put your code underneath a LAVA palette category is special and is something everyone should be trying to do. Let's all keep working on moving forward.

I really like the sounds of that! (as per my post above):

IMO, I don't think all submissions need this, but my idea is that LAVA should have another level of certification.

A higher level whereby releases would implement the above naming schema, and the code would be more tight and (kinda like NI's Add-on Developer levels) etc...

I would love to see that.

[Francois Normandin]

However a nice guideline would be to use the LAVA category as the main category and then you can put your branded category as a sub-palette of that if you like.

So if I hear you correctly, you mean that the LAVA palette should be restricted to Certified LAVAcr code. Right?

[Michael Aivaliotis]

So if I hear you correctly, you mean that the LAVA palette should be restricted to Certified LAVAcr code. Right?

That's exactly what I'm saying.

[Cat]

Every time I read the title of this thread, all I can think is, "We can't even standardize on how to spell standardise."

[jgcode]

Every time I read the title of this thread, all I can think is, "We can't even standardize on how to spell standardise."

Hey! Don't nock the English language!

[Aristos Queue]

The NI Example Finder already has a fairly extensive defined set of categories and search terms relevant to LabVIEW, programming, and the hardware LV is typically used with. It also has a mechanism for identifying VIs that are keyed with those search terms, and it can search both local harddrives and the online ni.com repositories. It may have other options for extending its search locations further.

The Example Finder is written entirely in G. I wonder how hard it would be to make it also search for packages?