Skip to main content
warning

There is a pending German patent application with the application number 10 2023 125 012.4. In order to use the TREND watermarker Software in the form published here, a patent license is required in addition to the license for the Software. See LICENSE for more information. In case of any questions or uncertainties, please contact us at trend@isst.fraunhofer.de.

info

This documentation is in a pretty early stage and updated continuously. Watch it!

Design Goals

  • Extensibility: the library is designed to allow easy extensibility for devs working on the core library as well as users of the library (but it has not been tested to see if this works as intended yet). Most functions only require interfaces instead of specialized classes to allow creating your own classes with different behavior.

    • Example: Interface FileWatermarker which allows adding support for other file types.

  • Flexibility: for most of the functionalities we created an interface and then implemented our default implementation. If this implementation does not meet the requirements, it can be exchanged with another class implementing the interface.

  • Usage: offering extensibility and flexibility often introduces a lot of complexity which makes it hard to understand how the library can and should be used. To make the usage easier we created convenient classes and functions which reduce the flexibility but should make it easy to use the library for general use-cases. Only users with special requirements have to look into the more flexible and complex API's.

    • Example: the classes Watermarker and JvmWatermarker offer functions to insert/extract watermarks into/from all supported file types/data without any additional configuration.

  • Performance: The library does not focus on performance. When ever we had to make a decision between performance and usability we chose the option for better usability.

  • Code quality: The code quality is very important for us. We want to ensure that every dev is able to work on the code base by providing documentation and enforcing a good code style by using linters. More information are collected in the Contributing section.

  • Testing: For every new code added to the library, tests have to be added to validate the functionality. This includes unit tests as well as integration tests. Furthermore, extensive tests also provide a good point of reference for new devs on how the code should be used.

  • Error handling: We handle errors (and warnings) as value, not as exceptions. Our library should not throw any exceptions, instead functions which can fail should return a Status or a Result if they return a value. See Concepts for details.

Devs working on the project need to understand these goals and implement them in their daily practice!