Modules missing README/xml docs in modules_s
acc_db acc_radius dialog diversion eval fifo oracle prefix_route print_lib unixsock
This propably is something that needs to be fixed before any release. For some modules, I belive you could steal from modules_k, that have similarity and all have docs.
Cheers, /O
On Thu, Oct 22, 2009 at 9:25 PM, Olle E. Johansson oej@edvina.net wrote:
Modules missing README/xml docs in modules_s
acc_db acc_radius
I can take care of these two.
dialog
I don't know much about this but I'll try to figure out. I think this is an internal module which is used by other modules and it was written by one of our guys. I'll see if there is any documentation available.
diversion
This module has README which was obviously generated from docbook, but docbook files are missing in the git repository. I'll look into it. By the way, this module is not really needed anymore, because everything the module does can be done directly in the configuration file.
eval
Eval module has a README which is not based on docbook, it was written by hand.
fifo
This module is not needed anymore, it is in the repository for historic reasons and we can remove it. The ctl module replaces the fifo module.
oracle
This module has a hand-written README. Theoretically, modules_s/oracle and modules_k/db_oracle should have been merged into one, just like we did it for other database drivers. However, it takes some work to update modules_s/oracle and this is a low-priority for me, because the module appears to be unmaintained.
prefix_route
I don't know much about this module, but there is README.
print_lib
This is an example module for developers, it does nothing.
unixsock
The same as fifo, we can remove it, it was replaced by ctl module.
-- Jan
On Freitag, 23. Oktober 2009, Jan Janak wrote:
oracle
This module has a hand-written README. Theoretically, modules_s/oracle and modules_k/db_oracle should have been merged into one, just like we did it for other database drivers. However, it takes some work to update modules_s/oracle and this is a low-priority for me, because the module appears to be unmaintained.
Hi Jan,
on the kamailio side i never get around to really test this one. It was contributed some time ago, but the developer did not did any updates later on. I fixed some time ago a bug which was introduced during some renames which was reported, and also Daniel mentioned sometimes (i think) that he knows about some people who using it.. So it seems that there are some users, but then they fix the bug perhaps in their internal repositories, so i also have the opinion that its more or less unmaintained right now.
Regards,
Henning
Henning,
On Fri, Oct 23, 2009 at 3:40 PM, Henning Westerholt henning.westerholt@1und1.de wrote:
On Freitag, 23. Oktober 2009, Jan Janak wrote:
oracle
This module has a hand-written README. Theoretically, modules_s/oracle and modules_k/db_oracle should have been merged into one, just like we did it for other database drivers. However, it takes some work to update modules_s/oracle and this is a low-priority for me, because the module appears to be unmaintained.
Hi Jan,
on the kamailio side i never get around to really test this one. It was contributed some time ago, but the developer did not did any updates later on. I fixed some time ago a bug which was introduced during some renames which was reported, and also Daniel mentioned sometimes (i think) that he knows about some people who using it.. So it seems that there are some users, but then they fix the bug perhaps in their internal repositories, so i also have the opinion that its more or less unmaintained right now.
OK, thanks for the info. So what if we (after we unfreeze again), move Kamailio's db_oracle into the shared module directory and get rid of modules_s/oracle? The module would be usable with Kamailio modules but not with SER modules. We can modify it to print an error message if somebody tries to use it with SER modules.
Over time we can either update the module so that both versions of the database API (if there is interest), or keep it that way.
I am sure that nobody is using the SER version of the module because it does not work anymore after my changes of the database layer and I think there is no need to keep it in the repository.
-- Jan
On Freitag, 23. Oktober 2009, Jan Janak wrote:
[..] OK, thanks for the info. So what if we (after we unfreeze again), move Kamailio's db_oracle into the shared module directory and get rid of modules_s/oracle? The module would be usable with Kamailio modules but not with SER modules. We can modify it to print an error message if somebody tries to use it with SER modules.
Over time we can either update the module so that both versions of the database API (if there is interest), or keep it that way.
I am sure that nobody is using the SER version of the module because it does not work anymore after my changes of the database layer and I think there is no need to keep it in the repository.
Jan,
this sounds good. The critical point is interest in the module, as its a bit hard to test, without it would not make sense to update it to the new API.
Regards,
Henning
23 okt 2009 kl. 15.20 skrev Jan Janak:
On Thu, Oct 22, 2009 at 9:25 PM, Olle E. Johansson oej@edvina.net wrote:
Modules missing README/xml docs in modules_s
acc_db acc_radius
I can take care of these two.
dialog
I don't know much about this but I'll try to figure out. I think this is an internal module which is used by other modules and it was written by one of our guys. I'll see if there is any documentation available.
diversion
This module has README which was obviously generated from docbook, but docbook files are missing in the git repository. I'll look into it. By the way, this module is not really needed anymore, because everything the module does can be done directly in the configuration file.
Ok.
eval
Eval module has a README which is not based on docbook, it was written by hand.
fifo
This module is not needed anymore, it is in the repository for historic reasons and we can remove it. The ctl module replaces the fifo module.
Even with code freeze?
oracle
This module has a hand-written README. Theoretically, modules_s/oracle and modules_k/db_oracle should have been merged into one, just like we did it for other database drivers. However, it takes some work to update modules_s/oracle and this is a low-priority for me, because the module appears to be unmaintained.
prefix_route
I don't know much about this module, but there is README.
print_lib
This is an example module for developers, it does nothing.
Still needs documentation that says "/* If you can't read C-code, then skip this module. */"
unixsock
The same as fifo, we can remove it, it was replaced by ctl module.
Thanks for feedback!
Removing modules is up to the rest of you to discuss... :-) /O
On Fri, Oct 23, 2009 at 4:04 PM, Olle E. Johansson oej@edvina.net wrote:
fifo
This module is not needed anymore, it is in the repository for historic reasons and we can remove it. The ctl module replaces the fifo module.
Even with code freeze?
No, I will wait with such changes, but it probably won't be included in the release.
print_lib
This is an example module for developers, it does nothing.
Still needs documentation that says "/* If you can't read C-code, then skip this module. */"
OK, that makes sense.
unixsock
The same as fifo, we can remove it, it was replaced by ctl module.
Thanks for feedback!
You are welcome, thanks for bringing all this up! Such lists of things we need to take care of are extremely useful for us. I think this kind of fresh perspective from someone who has not been working on the code for years is something we desperately need.
-- Jan
23 okt 2009 kl. 16.13 skrev Jan Janak:
On Fri, Oct 23, 2009 at 4:04 PM, Olle E. Johansson oej@edvina.net wrote:
fifo
This module is not needed anymore, it is in the repository for historic reasons and we can remove it. The ctl module replaces the fifo module.
Even with code freeze?
No, I will wait with such changes, but it probably won't be included in the release.
I guess I will mark these obsolete modules in README-MODULES as obsolete, deprecated, only for backwards compatibility or something...
/O