[clam-devel] ConfigurationProxy: següent passa

[Xavier Serra Román]

On May 27, 2011, at 2:21 PM, David García Garzón wrote:

> On Thursday 26 May 2011 22:33:34 Xavier Serra Román wrote:
>> On May 26, 2011, at 10:13 PM, David García Garzón wrote:
>>> Forwarded to the list, sorry, the original message from Xavi was in
>>> catalan.
>>> 
>>> A Dijous 26 Maig 2011 18:22:17, Xavier Serra Román va escriure:
>>>> Ei David!
>>>> l'altre dia vam parlar del camí a seguir amb el configuration i vas dir
>>>> Add, Removes... Amb això vols dir per exemple:
>>>> proxy["new_attribute"] = 'newvalue' ?
>>>> Fins ara sempre consideravem això com a AttributeError. I en cas
>>>> afirmatiu, com es fa? He vist el AddAttr_ de la interfície de
>>>> DynamicType però pren dos valors enters i és protected
>>>> 
>>>> Bye!
>>> 
>>> We should concentrate first in being able to do the same things that we
>>> support right now with dummy: Plain type checked attributes but no
>>> optionality (the add/remove thing you asked) and no composite
>>> attributes. Looking at the source i still miss some features for the
>>> clam config proxy:
>>> - Errors on accessing wrong attribs should match the ones raised by dummy
>>> - implement __setitem__ to set the config value.
>>> - Error on type missmatch al __setitem__
>>> - keys()
>>> 
>>> Once this is done, comparing dummy and clam tests they should be quite
>>> uniform. We can postpone optional and composite attributes implementation
>>> while going forward to something that it is usable yet, that is, being
>>> able to inspect the configuration of an actual processing inside a
>>> network and reconfiguring it. So lets consider how to implement
>>> Clam_NetworkProxy::processingConfig, first to get the actual
>>> configuration, then to modify it (how to apply the configuration which
>>> was a tricky issue).
>> 
>> Been thinking about that. What do you think of creating a function inside
>> Clam_NetworkProxy that returns a ConfigurationProxy (something like the
>> factory method we have inside Clam_ConfigurationProxy) and then pass that
>> method to the Configuration python object? It should look something like
>> this (in the Processing.py __init__):
>> 	self.__dict__["_config"] = Configuration.Configuration(
>> proxy.processingConfigProxy(processingType) )
> 
> It is not about the type, it is about the processing itself. you want the 
> processingConfigProxy to have access to the actual configuration values. So 
> the current interface should work. Just that what proxy.processingConfig(name) 
> should return is now a proxy (either dummy or clam), not a dict.
> 
> 

I have some questions then. In clam proxy processingConfig should ask the processing
for its config object and get the values from there right? How can I do that? I found no GetConfig()
method in <CLAM/Network.hxx> or <CLAM/Processing.hxx>

And the other question, how can I make processingConfig (clam proxy again) return a Clam_ConfigurationProxy?
So far in all my attempts all I got was a class named Clam_ConfigurationProxy but without any of its methods
implemented (just an empty Clam_ConfigurationProxy)

Bye!