Re: CR: Removal of persistent plugin data

Tad,

This looks like a few arbitrary utility methods of convenience now 
shoe-horned into the media platform object.  Given we are talking 
about the top level object of the framework, this is too prominent of 
a place to be placing this functionality.  Also, these methods are 
not to be available before platform is initialized and preferences created.

This functionality needs to be treated as any other service in the 
media platform.  We should name this IHXPersistentDataManager.  The 
functionality for this needs to be placed in a separate class 
CHXPersistentDataManager and in a separate files in 
\client\common\container\persistentdatamgr.cpp and 
\client\common\container\pub\persistentdatamgr.h .

The service (object) should be attempted to be obtained from the 
passed in context in CHXMediaPlatform::InitExtendableServices and 
failing there be created in CHXMediaPlatform::InitBasicServices. The 
QI for IID_HXPersistentDataManager.on media platform should be 
forwarded to created object.

Please rename RemovePersistentPluginData to RemovePluginData.  Since 
this the method on persistent data manger there is no need to 
emphasize persistent again and RemovePluginData is clear enough.

IHXPersistentDataManager service is to be available (code for it 
included in the media platform) only if 
HELIX_FEATURE_PERSISTENT_DATA_MANAGER is defined.

Note that CHXMediaPlatform::RemoveAllPreferences(void) is leaking 
pref2, pref3 and pPrefEnumerator.

Please fully fill out the CR from 
(https://common.helixcommunity.org/2005/patch/change-form) and 
document the methods - including the behavior and return codes.  You 
can paste the header documenting the API into the CR.  This will make 
it available to email archive searches.

I would be also very cool if you created a mini SOD on this feature 
under 
\helix-client\www\2009\devdocs\PDM-SOD-PersistentDataManager.txt 
documenting the intent, reasons (use-cases) and APIs.

Thanks,
Milko

At 07:24 PM 3/3/2009, Tad Yeager wrote:
>Proposed new interface is now called IHXMediaPlatformCleaner and has 
>three methods:
>
>HRESULT RemoveAllPreferences(void)
>HRESULT RemovePersistentPluginData(void)
>HRESULT RemoveNamedPreference(const char* pszPreferenceRootName)
>
>The MediaPlatform shouldn't have to be restarted. Generally, if 
>plugin data is missing from preferences, Plugin2Handler will 
>regenerate it.  The exception that necessitates the change we're 
>reviewing: if VerifyChecksum_ fails in 
>Plugin2Handler::ReadPluginInfoFast (or ReadPluginInfoSlow), 
>PluginHandlerData\FileInfoX is regenerated but 
>PluginHandlerData\PluginInfoX is not. This may seem like a bug, but 
>it prevents loading hacked plugins.
>
>MediaPlatform should be initialized before calling these methods. 
>MediaPlatform can be compiled and created with different features, 
>eg CreateMediaPlatformEx entrypoint and HX_FEATURE_FILEPREFS 
>preprocessor definition.  Preferences can be overriden by the 
>application, so we need the application to setup MediaPlatform 
>before calling any of these three functions.
>
>I've added checks and comments describing expected state.  I've 
>reworked the interface and implementation to enable removal of a 
>preference at an arbitrary level of the preference hierarchy, 
>allowing an application to remove only the preferences or mount 
>points that it cares about. I've put the code that removes all 
>preferences into its own function so that the parent-child 
>preference iteration would be more readable.  This duplicates a 
>small amount of code.
>
>Questions or comments?
>Thanks,
>Tad Yeager
>
>
>
>At 08:55 AM 2/25/2009, Greg Wright wrote:
>>Does the media platform need to be 'restarted' after prefs are deleted, or
>>perhaps re-initialized? We should make sure we define what state the platform
>>and engine are in after such a function is called as it can be called at
>>any time. Perhaps just not allowing the call after some point, not sure.
>>
>>Personally, I really don't like adding numbers to interfaces as we
>>have done historically. Sometimes there isn't a better choice, but
>>in this case I think it might be better named with something that
>>referes to the platforms persistent data. Then you could clone the
>>other calls like Purge() and Reset() into this new interface. Perhaps
>>calls for the PluginPath stuff as well. Might be useful to have an
>>interface you could pass around that does that kind of stuff but
>>doesn't have Close(), Init() or other types of calls.
>>
>>--greg.
>>
>>
>>
>>
>>
>>
>>Tad Yeager wrote:
>>>Resending because a portion of a reply wasn't transmitted and 
>>>there has been only one response.
>>>Synopsis: encapsulate the removal of persistent plugin data in the 
>>>MediaPlatform.
>>>Summary:
>>>Applications and browser plugins attempt to kill registry keys 
>>>prior to loading MediaPlatform/ObjectBroker so that plugin handler 
>>>data will be regenerated when mount points are added.  This 
>>>happens at installation time or if an application detects that 
>>>plugins have changed locations.
>>>The attached changes to MediaPlatform expose a method that deletes 
>>>preferences using code factored out of MediaPlatform's Reset() 
>>>function.  The location and format of the persistent plugin data 
>>>can change. The attached changes move ownership from 
>>>MediaPlatform's clients to MediaPlatform.
>>>Branchs:
>>>head, hxclient_3_1_0_atlas
>>>Affected: MediaPlatform.
>>>Risks: low.
>
>
>

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev