Re: [Wengophone-devel] Announcing Cobranding OpenWengo Enhancement Proposal
Aurélien Gâteau a écrit : Aurélien Gâteau a écrit : Hello, I have been working on improving cobranding support for the WengoPhone. I wrote an OpenWengo Enhancement Proposal (OWEP) about it. You can find it here: http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWEP_11388_Cobranding The document talks about a way to handle resources: by defining a new key type for the settings. After some initial work, I found out it would probably be a bit intrusive, so I would like to propose an alternative: defining a SettingsResourcesHelper class, which would work together with the CascadingSettings class to translate setting strings from/to resources path. Hum... I just realized this idea is not that lightweight: while there are getters for the resource keys in the Config class, there is no setters: code which need to set resource key values do so directly. This mean I would have to use my helper everywhere a resource is set. This does not sound like a good idea to me, it would be too easy to forget it and bypass the resource system. I think I will go back to introducing a new key type: 'resource'. Aurélien ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Announcing Cobranding OpenWengo Enhancement Proposal
Maxime Alexandre a écrit : Nice :) About the file format, why don't you use a standard format to store the data ? The thing is: we try to make the WengoPhone 2.1 easier to cobrand without making too many invasive changes. If it was up to me, I wouldn't be using XML to store config, or I would use something like this: settings option id=ringing.file type=pathsound/ringing.wav/option option id=sip.port type=integer5060/option /settings But as I said, it's not the goal of the cobranding branch. Aurélien ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Announcing Cobranding OpenWengo Enhancement Proposal
Aurélien Gâteau a écrit : Hello, I have been working on improving cobranding support for the WengoPhone. I wrote an OpenWengo Enhancement Proposal (OWEP) about it. You can find it here: http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWEP_11388_Cobranding The document talks about a way to handle resources: by defining a new key type for the settings. After some initial work, I found out it would probably be a bit intrusive, so I would like to propose an alternative: defining a SettingsResourcesHelper class, which would work together with the CascadingSettings class to translate setting strings from/to resources path. Given this config file: --- settings ringing.file stringsounds/ringing.wav/string /ringing.file /settings --- Here is how one would use SettingsResourcesHelper: --- CascadingSettings settings; SettingsResourcesHelper helper(settings); helper.setResourcesDir(/usr/share/wengophone); std::string ringingFile = helper.getKeyValue(ringing.file); // Now ringingFile contains /usr/share/wengophone/sounds/ringing.wav helper.setKeyValue(ringing.file, /usr/share/wengophone/sounds/monkey.wav); // Now the config file contains: // ringing.filestringsounds/monkey.wav/string/ringing.file helper.setKeyValue(ringing.file, /home/user/boom.wav); // Now the config file contains: // ringing.filestring/home/user/boom.wav/string/ringing.file --- As you can see, the idea is still the same: store a relative path if the resource path is inside resourcesDir, store a full path otherwise. This approach should be more lightweight than the previous because it does not require any modification of the *Settings classes. Does it sound good to you? Aurélien ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Announcing Cobranding OpenWengo Enhancement Proposal
Le 4 juin 07 à 13:07, Aurélien Gâteau a écrit : As you can see, the idea is still the same: store a relative path if the resource path is inside resourcesDir, store a full path otherwise. This approach should be more lightweight than the previous because it does not require any modification of the *Settings classes. Does it sound good to you? It sounds good for me :-) -- Philippe BERNERY [EMAIL PROTECTED] http://dev.openwengo.org ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Announcing Cobranding OpenWengo Enhancement Proposal
Nice :) About the file format, why don't you use a standard format to store the data ? DTD files are maybe more suitable : !ENTITY mywengo.ringing.file /home/user/boom.wav Is there a data type specification, or all the settings are strings ? Because you could have to store some booleans or integers. I suggest these kind of methods : getKeyStringValue(ringing.file); getKeyBoolValue(ringing.isReady); getKeyIntValue(ringing.volume); -- Maxime Alexandre OpenWengo Developper ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Announcing Cobranding OpenWengo Enhancement Proposal
Maxime Alexandre wrote: Another way to do it is to define CustomParams struct and to use boost::serialization to serialize it to XML boost::serialization does support structure versioning so back/forward compatiblity would be strightforward Vadim ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
