LabVIEW Framework for Creating Session-based APIs
The Extensible Session Framework (ESF) is designed to help create APIs that provides access to or control of a "session". That session could configure and control an instrument (like an IVI session), it could manage a communication link between two processes or devices on a network, it could open and manage a file in memory...we don't limit what a session is allowed to do, as long as it's characterized by the definition "a period of time devoted to a specific activity".
Description
The framework uses a single LabVIEW class -- your API is a child of that class -- to add several features to your API. It does this via two functions that are named "Obtain Session" and "Release Session" by default.
"Obtain Session" and "Release Session" are required in your API, but you can rename them and edit most of their behavior to act however you like. The attached slides provide a description and list of benefits. The demo projects are also attached as examples of using the framework.
Installation
VI packages for ESF are provided below and the latest version is available on the LabVIEW Tools Network VIPM repository.
The attached ZIP files contain additional examples showing APIs implemented using ESF.
Support
Please post questions, comments and feedback in the comments below.
What is the status of this framework?
Hi Terry,
The framework is still under active maintenance, and a few new features have been underway for a long time, targeted for release sometime this year. The most important new feature is the option to have a session managed by a daemon. This solves issues in which a session is initially obtained in a parallel thread which then finishes while the session is alive elsewhere. LabVIEW will automatically close the DVR in this case when the asynchronous VI exits memory, which will destroy the ESF session even if an independent handle exists in another thread.
This new implementation would result in the ESF session having the same lifespan as a queue, which will not be closed out automatically if another instance of the handle exists in a parallel thread. This will be an optional feature that can be decided per ESF class.
Michael,
Can you expand on this? What do you mean "obtained in a parallel thread"? I have never seen this behavior before so I am not certain I understand the context including in the Actor Framework. Do you mean a parallel application instance?
Matt
This is extremely useful package! I'm just wondering whether it is possible to publish it somewhere, so it will be accessible directly from VIPM. There is now Community edition of VIPM, and VIPM Community repository - which, I guess, perfectly suits to this package.
Because now it's a bit tricky to use this toolkit somewhere, and then build package based on ESF: in order to install ESF for the first time, one has to download it from here and install manually...