init bundle diff

[ransomw1c]

the bundle diff part of #214

[ransomw1c]

since #220 is a dep, i'll resolve conflicts after it lands

[galvare2]

What is the rationale behind this type of syntactic change?

[ransomw1c]

since the cmd/datamon/cmd package uses core.New (admittedly sugar), the main idea here is consistency.

now, the core.New itself is something that we could view as idiomatic, a sort-of borrowed idiom from Java, etc. where constructor functions are used. golang idioms are liable to change over time, yet in no small part because i buy into the utility of type inference, i suppose the constructor idiom is a helpful one: we get to treat the return values of constructors as semi-loosely (i.e. duck) typed.

[kerneltime]

Why not getBundleIDFromPath?

[ransomw1c]

i've added a getBundleIDFromPath function that returns a bundle id given the path to a bundle descriptor within the bundle (and the empty string when given another path such as a filelist path) and used it within setBundleIDFromConsumableStore.

it occurs to me that what getBundleIDFromPath could also mean is to get the bundle id from a path to a bundle on the local filesystem, except i suppose keeping the abstraction away from the local filesystem via storage is a desirable abstraction.

also, i could inline the contents of setBundleIDFromConsumableStore since it's only used once .. or not: i'm ambivalent re. the aesthetics of whether to maintain setBundleIDFromConsumableStore as a separate function or not.