Development of plugins for the backend compute node lag processing stage should be possible without having access to a complete backend system. It is already possible to run a backend compute node application instance on a workstation, and this section will describe what is needed to develop a plugin in such an environment. The focus will be on development for the lag processing stage in particular, as that is the only part of the backend system intended to be extensible.

To develop a plugin for the lag processing stage, one can run the lag processing stage application standalone, or through the backend compute node application. It will probably be most useful to run the lagset_pipeline application, as running the full compute node application requires a lag frame source. On the other hand, running lagset_pipeline requires a lag set source instead, but a file-based lag set source should be easier to generate than a lag frame source, since most of the WIDAR hardware-specific fields are not contained in a lag set. Once in possession of a file of lag sets appropriate to the plugin being developed, one also needs a configuration file for the lag processing stage. Creating a configuration file for this narrow purpose should prove fairly simple, but this process has not been attempted, so there is some uncertainty. Ultimately, a tool to create lag sets together with an appropriate configuration file might be useful, but experience developing plugins is a prerequisite to designing such a tool.

To ensure that the plugin development environment is compatible with the deployment environment, it may be useful to create a development toolkit. A toolkit of this kind would comprise customized makefiles together with the copies of the source code for libraries deployed on the target backend system. This toolkit should be relatively easy to create, will greatly ease plugin development, and will minimize problems caused by differences in the development and deployment environments.

GStreamer elements are based on GLib's GObject object-oriented framework for C. While this framework is well developed and widely used, it will not be familiar to most programmers. There are complexities in the GObject approach that take some time for a new developer to understand, but, in the limited scope of developing new backend elements, the complexities can be minimized, and the development can be guided by employing the object-oriented nature of GObject. A good example of this approach is GStreamer itself, which provides base classes for the development of certain types of elements, such as filters, sources and sinks. For backend plugin development, even more narrowly defined base classes can be prepared to simplify the development of new elements. What classes, exactly, would be needed in this approach, while now uncertain, will become clearer as development of the core pipeline elements proceeds.