Higher level API fors reading known/simple property sets

[Numpsy]

As it stands, the OlePropertiesContainer API is quite low level. This gives it a nice flexibility, and makes it usable for 'unknown' sets, but also requires a bit of extra work on the user side when doing simple operations (e.g. knowing what PID a property has, and making sure know properties have the expected type when adding them).

In v2 there was this SummaryInfoProperties class, but it wasn't hooked into anything -

openmcdf/sources/OpenMcdf.Extensions/OLEProperties/OLEPropertiesContainer.cs

Line 45 in 03ef8cb

public class SummaryInfoProperties

/

openmcdf/sources/OpenMcdf.Extensions/OLEProperties/OLEPropertiesContainer.cs

Line 66 in 03ef8cb

public static OLEPropertiesContainer CreateNewSummaryInfo(SummaryInfoProperties sumInfoProps)

So, I wonder if there's interest in adding things like
Numpsy@59fac64 (plus write equivalent)

This could be done externaly on top of OleProperties, but doing it internally has the advantage that it can read the data directly from PropertySetStream rather than having two layers of mappings (TypePropertyValues -> OleProperties -> end class)

[jeremy-visionaid]

With the usual preface of me not knowing/using OLE and therefore not having fully considered all the options/consequences... It looks to me like the TypedPropertyValue class maybe just shouldn't exist. The equivalent in native implementations would be likely be handled as a variant. However, in the dotnet world, you likely don't really need variants most of the time (since things can be boxed into an object). Basically, I'd expect to see something more like a discriminated union, but also be thinking about how to make variants and objects play nicely together so consumers can leverage features like pattern matching etc..

I'd then expect well-known property sets to be handled via adding types which encapsulates each well-known set them rather than multiple classes that group otherwise unrelated values together (FormatIdentifiers, PropertySetNames).

[Numpsy]

'd expect to see something more like a discriminated union

Yes, but this is still a 'lower level' api - e.g. someone adding a 'known' property of a numerical type still needs to know whether to add it as I2/I4/UI4 etc.

I'd then expect well-known property sets to be handled via adding types which encapsulates each well-known set

I assumed that was the original idea of SummaryInfoProperties - but just as a DTO with all the possible properties in the correct types, and not bound to any other implementation details

[jeremy-visionaid]

Yes, but this is still a 'lower level' api - e.g. someone adding a 'known' property of a numerical type still needs to know whether to add it as I2/I4/UI4 etc.

Indeed, but the suggestion included an approach for the higher level API to depend on things that might be considered tech debt. Adding a new API on top of that might make the situation worse. So, my wider point is that I'd be thinking about improving/changing the core implementation before adding something new.

[jeremy-visionaid]

FWIW, The structured storage reference wrapper exposes types for handling property sets (albeit not in a cross platform way of course).

There's a pretty reasonable sample in the StructuredStorage definition of Windows.Win32.System.Com.StructuredStorage.PROPVARIANT from CsWin32. It could be used to inform a design for changing the OpenMcdf.Ole API.

Maybe a lot of cases can then be covered with VariantToPropVariant and Marshal.GetObjectForNativeVariant to make it a bit friendlier?