Why does a "sublibrary" need to know which libraries its included in?

[WavePacket]

---

@crossrulz wrote:

---

@WavePacket wrote:

PPLs seemingly fulfils my desire to distribute a single "something" to other developers, and keeps things encapsulated, right?

---

...

But PPLs are also extremely useful for plugins when combined with Object Oriented Design.  Think Hardware Abstraction Layer here.

---

Interesting. Mind writing a few more sentences here to connect the dots a bit for me (just at a conceptual level)? I always like to keep learning about good software engineering.

[FireFist-Redhawk]

Not sure if this is the direction that crossrulz is going, but check out this article, the setup does have a good bit of steps involved but it is just so cool.

[Mark_Yedinak]

A plugin architecture makes it easy for you to deploy new types of an item without having to release a new version of the application. For example, let's say you use a DMM in your system. Using PPLs you can define a base level class is a virtual definition of the class. Meaning very few if any methods are implemented in the class itself. You need to define a good API for the class to allow for re-use. Now when you buy Acme's DMM and use it you implement the child class of your base DMM class. This implementation allows you to use the Acme DMM in your application. The application itself is developed using the virtual base level class. At runtime, generally during initialization your application loads the specific implementation it needs for the DMM. You just need some way to let the application know which specific version of the DMM you want. Now sometime in the future you get a new DMM from Megacorp. You can now implement a version of your DMM class for this particular instrument. Now your application can run using either type of DMM. At runtime it simply loads the correct type it will be using. To support more types of DMMs you simply need to implement child classes for each. To ad support for a new type of device you just put a new copy of the PPL on the machine and now your application can use either the specific one needed. As long as you adhere to your API you can add as many types of DMMs as you like. the decision on which specific one is used is made at runtime and the correct PPL is loaded at that point.

[WavePacket]

---

@Mark_Yedinak wrote:

A plugin architecture makes it easy for you to deploy new types of an item without having to release a new version of the application. ...

---

Fascinating.

So as another potential example, let's say that I put these types of PPLs on a network folder where all the test computers look too. As soon as I add another PPL for a new brand of instrument, all test software across the network could now use that new instrument? (This of course means that if the network goes down, all test softwares would too...)

[Mark_Yedinak]

Yes, that is one possible to share the PPLs across multiple applications and machines. The path to the shared folder would have to be managed properly. Also, using this approach you have to be very diligent about maintaining your API so things don't break. We have found at times we would need to rebuild an application. Obviously it is important to work within a single version of LabVIEW. Mutli-version LV support in PPLs is supposed to be possible in the latest versions of LabVIEW but we have experimented with this yet to know if it truly works.

In our case we update applications by distributing the plugins and applications using the NI Package Manager. We have not tried using a network share.

[FireFist-Redhawk]

---

@WavePacket wrote:
(This of course means that if the network goes down, all test softwares would too...)

---

We still deploy applications the old fashioned way, tried to convince my boss to get on board with this new concept but he's overcautious about test kits going down. So I'm not saying this from experience or anything, but I think somehow or another you would want to have and use local copies of the PPLs on each computer and not actually have anything use the PPLs on the network (just copy them). The big reason would be because of what you just said, but I feel like you'd also have a hard time updating the PPLs without breaking anything, if there were apps continuously using the PPLs on the network.

Of course if there is a critical update and the network is down, and all the apps can do is use the latest version of what's already on the local computer...

[rolfk]

---

@Mark_Yedinak wrote:

A plugin architecture makes it easy for you to deploy new types of an item without having to release a new version of the application.

---

But for the sake of your sanity design first, think twice, and test triple and then again before planning to do that for more than one platform. LabVIEWs current ability to deal with PPLs for more than one platform are extremely brittle and can break easily from totally harmless actions.

If you only develop for Windows OR Linux OR Mac, it's ok, but as soon as you also include a mix of them AND/OR RT targets as well, things very quickly go downhill for now.

[crossrulz]

---

@WavePacket wrote:

So as another potential example, let's say that I put these types of PPLs on a network folder where all the test computers look too. As soon as I add another PPL for a new brand of instrument, all test software across the network could now use that new instrument? (This of course means that if the network goes down, all test softwares would too...)

---

Also keep in mind you need something to tell the application to look for a specific plugin.  What I do is standardize on a specific directory structure and then use a configuration file of some kind (ini, JSON, or XML) to tell the application which class to look for in the specific directory (relative paths help a lot here).  So if I change DMMs, I just have to update that configuration file to point my application to the right plugin (and whatever other configuration parameters I may need to update) and everything else just works.

[crossrulz]

---

@Mark_Yedinak wrote:

In our case we update applications by distributing the plugins and applications using the NI Package Manager. We have not tried using a network share.

---

I have just started doing this.  It has worked so far, but I have not really done it enough to say I'm confident in it.

[Mark_Yedinak]

---

@rolfk wrote:

---

@Mark_Yedinak wrote:

A plugin architecture makes it easy for you to deploy new types of an item without having to release a new version of the application.

---

But for the sake of your sanity design first, think twice, and test triple and then again before planning to do that for more than one platform. LabVIEWs current ability to deal with PPLs for more than one platform are extremely brittle and can break easily from totally harmless actions.

If you only develop for Windows OR Linux OR Mac, it's ok, but as soon as you also include a mix of them AND/OR RT targets as well, things very quickly go downhill for now.

---

So far I haven't had to do cross platform distributions. I have given it some thought though about needing to include an RT environment but haven't had to tackle that yet. One thing I would consider would be to use a VM for each platform. With source code control and the compiled code separated from the source each VM would cover a single platform. I'm thinking this should work but haven't tried it yet.