Update existing module or create new?
All, We are working on a memcached module which uses the libmemcached library, as opposed to the (no longer under active development) libmemcache that the existing module depends on. Am I correct in thinking that in this instance, it would be better to create a brand new module (with a different name) rather than modify the existing one? In addition to changing the dependency, we will also be exporting new commands and potentially changing the format of the exported PVs. Regards, Charles -- www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
Am Dienstag, 5. Februar 2013, 12:52:19 schrieb Charles Chance:
We are working on a memcached module which uses the libmemcached library, as opposed to the (no longer under active development) libmemcache that the existing module depends on.
Am I correct in thinking that in this instance, it would be better to create a brand new module (with a different name) rather than modify the existing one? In addition to changing the dependency, we will also be exporting new commands and potentially changing the format of the exported PVs.
Hello Charles, as the original author of the module I'd think that changing or replacing the existing module would be the way to go. So far I'd not recieved that much of bug reports against the existing module. And as Alex Balashov also mentioned recently, there are some other issues with the current library. If existing users need to stay with the old module, its available in the git and the existing releases, for the new release we should go with a module which supports the newer library. It would be nice if you could stay with the existing PV API, which I modelled somehow after the htable module. If you need to change something, just announce it on the devel list and ask for feedback. Thanks and regards, Henning Westerholt
Hello Henning, On 05/02/2013 12:25, Henning Westerholt wrote:
Am Dienstag, 5. Februar 2013, 12:52:19 schrieb Charles Chance:
We are working on a memcached module which uses the libmemcached library, as opposed to the (no longer under active development) libmemcache that the existing module depends on.
Am I correct in thinking that in this instance, it would be better to create a brand new module (with a different name) rather than modify the existing one? In addition to changing the dependency, we will also be exporting new commands and potentially changing the format of the exported PVs. Hello Charles,
as the original author of the module I'd think that changing or replacing the existing module would be the way to go. So far I'd not recieved that much of bug reports against the existing module. And as Alex Balashov also mentioned recently, there are some other issues with the current library.
If existing users need to stay with the old module, its available in the git and the existing releases, for the new release we should go with a module which supports the newer library.
It would be nice if you could stay with the existing PV API, which I modelled somehow after the htable module. If you need to change something, just announce it on the devel list and ask for feedback.
Thanks and regards,
Henning Westerholt
We have indeed used the module in the past with no issues - so thank you for writing and sharing :) Very happy to stay with existing PVs if possible. The only thing I'd like to see different is to set value and expiry at the same time, instead of having to set value, then alter expiration. This has to be better than setting a value with some default expiry, getting that same value back again, then re-setting the value once more with a different expiry? Could this be implemented at PV level? Something like $mct(key:expiry) = value? And if expiry is omitted, we use default set in params. Regards, Charles -- www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
Am Dienstag, 5. Februar 2013, 13:55:41 schrieb Charles Chance:
as the original author of the module I'd think that changing or replacing the existing module would be the way to go. So far I'd not recieved that much of bug reports against the existing module. And as Alex Balashov also mentioned recently, there are some other issues with the current library.
If existing users need to stay with the old module, its available in the git and the existing releases, for the new release we should go with a module which supports the newer library.
It would be nice if you could stay with the existing PV API, which I modelled somehow after the htable module. If you need to change something, just announce it on the devel list and ask for feedback.
We have indeed used the module in the past with no issues - so thank you for writing and sharing :)
Very happy to stay with existing PVs if possible. The only thing I'd like to see different is to set value and expiry at the same time, instead of having to set value, then alter expiration. This has to be better than setting a value with some default expiry, getting that same value back again, then re-setting the value once more with a different expiry?
Could this be implemented at PV level? Something like $mct(key:expiry) = value? And if expiry is omitted, we use default set in params.
Hi Charles, thanks, good to know that you use it. :-) With regards to the expiry value, yes I think this could be implemented like this. Just one remark, the syntax that other PVs uses is "=>", like in http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#sht_htable_key Then it would be $mct(key=>expiry) = value Best regards, Henning Westerholt
Hi, On 06/02/2013 15:16, Henning Westerholt wrote:
Am Dienstag, 5. Februar 2013, 13:55:41 schrieb Charles Chance:
as the original author of the module I'd think that changing or replacing the existing module would be the way to go. So far I'd not recieved that much of bug reports against the existing module. And as Alex Balashov also mentioned recently, there are some other issues with the current library.
If existing users need to stay with the old module, its available in the git and the existing releases, for the new release we should go with a module which supports the newer library.
It would be nice if you could stay with the existing PV API, which I modelled somehow after the htable module. If you need to change something, just announce it on the devel list and ask for feedback. We have indeed used the module in the past with no issues - so thank you for writing and sharing :)
Very happy to stay with existing PVs if possible. The only thing I'd like to see different is to set value and expiry at the same time, instead of having to set value, then alter expiration. This has to be better than setting a value with some default expiry, getting that same value back again, then re-setting the value once more with a different expiry?
Could this be implemented at PV level? Something like $mct(key:expiry) = value? And if expiry is omitted, we use default set in params. Hi Charles,
thanks, good to know that you use it. :-) With regards to the expiry value, yes I think this could be implemented like this. Just one remark, the syntax that other PVs uses is "=>", like in http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#sht_htable_key
Then it would be $mct(key=>expiry) = value
Best regards,
Henning Westerholt
We now have an updated memcached module, working with libmemcached and also with the added ability to (optionally) specify expiry in the format $mct(key=>expiry). How do we get these changes pushed back into the master? Regards, Charles -- www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
http://sip-router.org/contribute/ http://sip-router.org/tracker/ Regards, Ovidiu Sas On Thu, Feb 21, 2013 at 5:37 PM, Charles Chance <charles.chance@sipcentric.com> wrote:
Hi,
On 06/02/2013 15:16, Henning Westerholt wrote:
Am Dienstag, 5. Februar 2013, 13:55:41 schrieb Charles Chance:
as the original author of the module I'd think that changing or replacing the existing module would be the way to go. So far I'd not recieved that much of bug reports against the existing module. And as Alex Balashov also mentioned recently, there are some other issues with the current library.
If existing users need to stay with the old module, its available in the git and the existing releases, for the new release we should go with a module which supports the newer library.
It would be nice if you could stay with the existing PV API, which I modelled somehow after the htable module. If you need to change something, just announce it on the devel list and ask for feedback.
We have indeed used the module in the past with no issues - so thank you for writing and sharing :)
Very happy to stay with existing PVs if possible. The only thing I'd like to see different is to set value and expiry at the same time, instead of having to set value, then alter expiration. This has to be better than setting a value with some default expiry, getting that same value back again, then re-setting the value once more with a different expiry?
Could this be implemented at PV level? Something like $mct(key:expiry) = value? And if expiry is omitted, we use default set in params.
Hi Charles,
thanks, good to know that you use it. :-) With regards to the expiry value, yes I think this could be implemented like this. Just one remark, the syntax that other PVs uses is "=>", like in http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#sht_htable_key
Then it would be $mct(key=>expiry) = value
Best regards,
Henning Westerholt
We now have an updated memcached module, working with libmemcached and also with the added ability to (optionally) specify expiry in the format $mct(key=>expiry).
How do we get these changes pushed back into the master?
Regards,
Charles
-- www.sipcentric.com
Follow us on twitter @sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
Am Donnerstag, 21. Februar 2013, 23:37:07 schrieb Charles Chance:
[..] We now have an updated memcached module, working with libmemcached and also with the added ability to (optionally) specify expiry in the format $mct(key=>expiry).
How do we get these changes pushed back into the master?
Hello Charles, sounds great! If this is a smaller patch, it could be simply applied to the git master branch from a developer, after the branching of the 4.0 version next week. Ovidiu sended you some informations about that already. But I assume its a more intrusive change which maybe also bring some new bugs etc...? Do you plan to do more work on this module? Best regards, Henning Westerholt
Hi Henning, On 22 February 2013 13:19, Henning Westerholt <hw@kamailio.org> wrote:
Am Donnerstag, 21. Februar 2013, 23:37:07 schrieb Charles Chance:
[..] We now have an updated memcached module, working with libmemcached and also with the added ability to (optionally) specify expiry in the format $mct(key=>expiry).
How do we get these changes pushed back into the master?
Hello Charles,
sounds great! If this is a smaller patch, it could be simply applied to the git master branch from a developer, after the branching of the 4.0 version next week. Ovidiu sended you some informations about that already.
But I assume its a more intrusive change which maybe also bring some new bugs etc...? Do you plan to do more work on this module?
Best regards,
Henning Westerholt
The structure is very much the same as before, but I think it is more than a small patch. There is certainly potential for new bugs! I do plan to add multi-server support at some point and I am happy to maintain/bug fix where necessary. Also happy to update the documentation. Other than that, there's not much more to add at this time. Regards, Charles -- www.sipcentric.com Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
Hello Charles, sorry for the late reply. Your ideas sounds interesting, multi-server support would be indeed useful. You can send me the patch directly then I can review it, give you feedback and integrate it then to the master branch. Thanks and regards, Henning The structure is very much the same as before, but I think it is more than a small patch. There is certainly potential for new bugs! I do plan to add multi-server support at some point and I am happy to maintain/bug fix where necessary. Also happy to update the documentation. Other than that, there's not much more to add at this time. Regards, Charles www.sipcentric.com<http://www.sipcentric.com/> Follow us on twitter @sipcentric<http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
participants (4)
-
Charles Chance -
Henning Westerholt -
Henning Westerholt -
Ovidiu Sas