Before integrating new technologies, it is important to assess which protocol is the best to use for discovering data.
Consider the performance aspects of your implementation, does SNMP return a lot of useless information along with the correct information? Is SNMP really slow compared to HTTP or vice versa.
Sometimes you have no choice but to use a particular protocol as the information you need is only available that way.
The choices you make in these early stages are important to try to get right as all future fixes and updates to your processor are limited to this implementation unless the decision is taken to re-write the discovery process to use a different protocol or collect and parse data a different way. This is a time-consuming process so a little time spent coming to the correct decision at the start of the implementation can save a lot of future headaches.
The new RDF has a wide range of different protocols supported compared to the old RDF which just had 2 - SNMP, HTTP and database. Having a lot more choice in how you can discover data gives you more options to collect data in the correct way with best-suited information.
It will be tempting to make changes to an existing Processor class, especially when new versions of remote devices become on-line in production. This may lead to version incompatibility issues. Careful considerations need to be made along with testing to ensure updates do not break or cause issues with previous versions with a given technology.
If this is not possible, for example, a new device version cannot be supported correctly in an existing processor class without breaking older versions, you can make a new processor for this version. Make use of the 'is compatible' method which allows for the RDF agent to call different processors for different device versions.
When creating processors you are doing so in an active code which is shared with other developers and operations engineers. Like with any code project, the goal when writing code is to have it as clean and concise as possible. Readability is very important if someone has to update your code it is extremely helpful if the code speaks for itself and everyone understands what the code is trying to achieve. If some obscure code is unavoidable, leave a small comment and explain why and not how this helps greatly.
Currently there are no defined templates on how to structure processor class e.g with helper methods etc we hope to in the future.
If you find yourself repeating code then make sure there is not already a helper class for it considering creating one.
If a helper class is there but it does not account for this, consider adding your own reusable code to the helper class if it will benefit others.
Currently, the guideline is to make a single java class per version range which implements all the discovery interfaces which are supported for that device and version range.
Packages in the RDF Agent structure should correspond to the device technology e.g com.errigal.rdf.processing.technology.CombaFlexMBDA
Please do not update or change any of the core classes outside of the technology package. At this current moment in time, there should be no need to update any of the classes outside of this package. From a processor implementation point of view, everything you need should be readily available and to hand.