Implement load from property bag with loading topology from XML file

[roman380]

Filter data is currently stored as Base64 encoded persistent stream data, which is good.

For development purposes, it might be convenient to store property bag instead, so that it's easily editable. For example stream and bag:

<filter name="Some Filter" index="2" clsid="{AF469F88-4439-4B8B-86CC-24925C563CAD}">
    <ipersiststream encoding="base64" data="AAwAAA=="/>
</filter>
<filter name="Delivery Delay" index="4" clsid="{E7DC1EDC-9A89-47A3-AFAE-C3AF7A932A94}">
  <ipersistpropertybag>
    <property name="Delay" value="1000" />
  </ipersistpropertybag>
</filter>

Basically saving to bag makes also sense as an option, but stream is more reliable. It might make sense to save both and load from stream, or bag as a second chance. Anyway, I am going to add load from bag now, and the rest might be not worth the effort.

[mikecopperwhite]

Interesting idea. I like the idea of the data being more readable. Some of my filters write Unicode String data to properties which is editable in GRF in a hex editor but not in GRFX ironically because of the base64 encoding. If it was encoding as something like UTF8 then that would be much easier to read and edit.

How would property bag support work at the filter level? Would this require the filter to support this style of persistence by querying for the IPersistPropertyBag interface and using that instead of IStream?

[roman380]

This is fully COM compliant. I have a filter that implements both IPersistStream and IPersistPropertyBag (well, actually I have lots of such since with ATL this is straightforward) and the commit I made already does everything necessary:

• GSN goes ipersistpropertybag branch
• GSN builds natively IPropertyBag backed by contents of ipersistpropertybag node
• IPersistPropertyBag::Load call invites the object to load the properties it wants

Now your question about property page. This has zero interference with property page. Property page still talks to object via interfaces, updates the same properties from code. Loading from stream or bad makes no difference, saving makes no difference either.

An addon possible is a new property page: when GSN sees IPersistPropertyBag, it can invite to save to in-memory bag, then display the properties visually. That would also be a nice thing.

When saving, GSN can detect availability of IPersistStream and IPersistPropertyBag and write both into XML. Why not? Binary stream + human readable data redundantly duplicated.

There is a question of string conversion, Property values are variants, they might not have string conversion OR strings conversion might get incompatible when regional settings change. It is more reliable to load from binary data rather than from properties. What makes sense to me is to give priority to load from stream. If developer wants the bag, he can edit the XML and delete ipersiststream fragment so that ipersistpropertybag has effect.

Sorry for chaotic notes :)