View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005587||SUMo||New Feature||public||2019-07-20 15:39||2019-07-20 19:28|
|Target Version||Long term|
|Summary||0005587: differentiate scanning and reporting levels and make them configurable|
|Description||SUMo doesn't seem to have a clear definition yet of its (external) objects and their versions. It has some definition but doesn't seem to stick at it closely. Instead of handling all its objects universal, often a distinguished handling is preferrable. With external objects I mean products and their components for which SUMo shall detect presence, version and report available updates.|
I'd like to have a hierarchy of object definitions. And then I like to configure SUMo to report according to interested and configured object scope. Scanning and checking may be performed on all hierarchy levels at once or in phases, preferring phases in order to limit blocking times and become able to already report on more abstract level while processing of lower level may still go on.
I don't know what the most abstract objects may be. I guess some multi-cloud applications or distributions on the top.
On the lower level, I suggest some cloud applications or distributions. This may include multi-datacenter applications too.
On the lower level, I suggest some data center applications or distributions.
On the lower level, I suggest system and application distributions like operating systems (Windows in all its editions) in the larger sense, not just the kernel.
On the lower level, I suggest some application bundles like local office software (like Microsoft Office, LibreOffice), local document processing bundles (like LyX) or development suites (like Visual Studio, Eclipse, GCC Suite, Strawberry Perl). I suggest to place multi-product products on the same level.
On the lower level, I suggest some applications at product level (like Microsoft Word or a gcc compiler).
On the lower levels, I suggest a dynamical hierarchy of product components not distributed seperately, like plug-ins, extensions, shared and non-shared libraries.
On the lowest level, I suggest files, if still needed as seperate object. I know that a single file may include several (possibly bundled or configurable) components. I assume this possible not only for archive and package files.
I know that limits on these abstraction levels are not fixed and may change over time. While Microsoft Office has been a local bundle in the past, there exist editions in the mean time which are cloud based. The same applies to ERP systems and similarly to database management systems, eventually depending on runtime configuration.
Scanning, detection and checking shall be able to address all these abstraction levels, including their relations. And reporting shall become able to switch between these levels, preferrable without rechecking. So reporting will need an extension in order no to be limited to sorting but become able to filtering too, including filtering on selectable abstraction level.
Without such differentiated abstraction and reporting some SUMo bugs may not get fixed!
While some software product publishers assign the same version to a product as to its components, others keep their versions independant with the product level specifying which components with which versions are components of the same product version, like manifests for .Net applications. Don't know yet to which abstraction level to associate which kind of assemblies. For various software (and auditing) disciplines these independant versioning is strongly preferred.
Depending on software and product composition architecture, updates to components may be possible below the product level! SUMo is not yet sufficient to detect nor to report such situations although already making appropriate and inappropriate update availability report claims!
Mixing these abstraction levels as currently implemented in SUMo is confusing!
|Additional Information||This feature request is no duplicate to feature request https://www.kcsoftwares.com/bugs/view.php?id=5442 although being related. That other issue is focusing only on a subset on reporting and configuration while this feature request has a much broader scope.|
|Tags||No tags attached.|
|2019-07-20 15:39||wolf||New Issue|
|2019-07-20 19:28||Kyle_Katarn||Relationship added||related to 0005442|
|2019-07-20 19:28||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2019-07-20 19:28||Kyle_Katarn||Status||new => acknowledged|
|2019-07-20 19:28||Kyle_Katarn||Target Version||=> Long term|