Too many constructors

[markuskont]

See: #6 (comment)

It seems to me that I made too many constructors. This can be confusing when trying to implement new features, as contributors might be unsure what is needed and what not. In truth, those constructors were created as at the time it was simply a research project and I was the only user of the tool. So some helper constructors were made as quick fixes to simplify integrations. In other cases I needed granular steps that could be easily reported in testing utilities.

They should be refactored to reflect real-world use cases.

[newodahs]

So I think reducing the constructors to the following for public consumption makes sense to me (what follows is wildly raw so bear with me):

1. Wide constructors to read from filesystem directory (what we have today: NewRuleset)
   • I think this is more for legacy/R&D; see next
2. Slightly smaller constructors to generate rules from []byte directly (caller handles reading in the data from it's source, API parses it)
   • Something like NewRulesetFromYAML and NewRulesetFromJSON
     • As an implementation note, you could easily see providing a JSON array of rules to something like NewRulesetFromJSON, maybe the YAML version though is a map of []byte where each key in the map is a rule-name identifier; perhaps this applies to a JSON format too where each individual rule in the array is actaully part of a named key...
   • The idea here is to allow the consumer of the API to handle getting the data from /somewhere/ while the API handles unmarshalling, parsing, and validating the passed raw data
     • The use case for the above is to allow storing the YAML or JSON form of the sigma rules somewhere other than a filesystem with full files and extensions; ex. a database field (PostgreSQL has really good support for json as a native datatype).
     • This is especially valuable in multi-tenant environments where you may not want to manage individual file system layouts per tenant on disk.
3. Drop all other constructors (or rather, make them private for internal use); I don't know if there are valuable uses for more constructors from a consumer standpoint; ex. a singular rule loaders doesn't make sense as you'd just call NewRuleSet with a list of one rule, etc...