Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer - one big example configuration - probably harder to understand - easier to maintain for us - one example config file per "feature" - probably easier to understand your desired "feature" - you might have problems to integrate all your desired "features" into one config without breaking anything - harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils
Instead of one big example, you can provide some big example in order to cover "main desired feature", easy to maintain :D
2007/5/14, Nils Ohlmeier nils@iptel.org:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Ideally, I'd like to see:
-One big configuration, well documented (per line or per block at the VERY least). -Smaller configuration examples for options that might not fit into a larger overall config (block-level, which blocks/modparams/etc in the large config would be replaced with/added by the option blocks provided; detailed documentation on the blocks and modparams and what they do/mean (perhaps with links to the proper lines in the module documentation).
That way you're not keeping separate configs for each option (unless it's something that completely replaces all the rest of the config), and as more tricks/suggestions come up, it's easier to add an option or two to the options sections since they're just small blocks of code.
Just an idea.
N.
Hi Nils, Good initiative! I think we need to coordinate our efforts so we avoid duplicate work. ONsip.org and iptel.org merged partly because we wanted to align the SER - Getting Started configuration files with the development of SER. As you probably have seen on the lists, the intention is to add the document and the config files to the cvs (SER 2.0). Most beginners of SER (and many OpenSER beginners) start out with the SER - Getting Started document and configs. From what I have seen, there are now many, many production configs out there using the basic structure from the getting started files.
We have learned quite a lot about maintaining example configuration files: 1. People need small pieces in order to understand how each feature is implemented 2. Without an expert pre-integrating configs/features, many/most? people struggle to integrate a feature into another config 3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a document with commented config files. We made the config files available standalone (ready to be run) and subsequently focused more and more on maintaining the configuration files and add more features and then let the comments/document come afterwards. Keeping everything in sync was a problem. We had early decided to keep everything in one common structure and let each config build on each other (to incrementally add functionality). This helped us in making sure everything worked and people didn't have to integrate small examples into one big themselves.
Our biggest problem was to keep adding features and making sure that we updated configs to new SER versions.
Based on these experiences, we have done the following: - Migrated the document to docbook - Created the m4 build system (http://www.iptel.org/ser/doc/buildsystem) which keeps the configuration files WITH comments and allows auto-generation of the commented config ready for inclusion in SER - Getting Started document
In creating the build system, I put emphasize on the capability to maintain different configuration sets (called feature packages, ex. gettingstarted) composed of different feature sets (helloworld, auth, natrtpproxy etc), each consisting of a set of features (natdetection, natmangling, etc). The configuration files are easier to maintain and as added value, people can automatically generate their config file based on an example with correct IP address, port etc. (BTW, I work on allowing people to generate their config files directly from from iptel.org)
This may sound complicated, but I believe a quick look at the doc (http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the current ser.cfg config with the optimized NAT example, and we will try to use that config as a starting point for a new NAT SER - Getting Started configuration file.
I don't think everything should go into the SER - Getting Started feature package (though we should at least avoid creating two versions of exactly the same functionality), but I hope you will spend some minutes to see how a new feature package in the build system can help your goals. I will of course be happy to assist you (as I have waited to see interest before documenting creating new feature packages). g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Indeed, a coordination of these two efforts would be ideal. The OnSIP Getting Started documentation was(is) well documented and shows essentially a large configuration example with added options and detailed information about the options themselves.
More than once, I found myself referring to it for both debugging what I might have done wrong, and for an understanding of what configurations options do what. The module documentation is one thing, but more often than not, a lot more is needed than just a simple function definition in order to truly understand how a function behaves and should be implemented.
Greger V. Teigre wrote:
Hi Nils, Good initiative! I think we need to coordinate our efforts so we avoid duplicate work. ONsip.org and iptel.org merged partly because we wanted to align the SER - Getting Started configuration files with the development of SER. As you probably have seen on the lists, the intention is to add the document and the config files to the cvs (SER 2.0). Most beginners of SER (and many OpenSER beginners) start out with the SER - Getting Started document and configs. From what I have seen, there are now many, many production configs out there using the basic structure from the getting started files.
We have learned quite a lot about maintaining example configuration files:
- People need small pieces in order to understand how each feature is
implemented 2. Without an expert pre-integrating configs/features, many/most? people struggle to integrate a feature into another config 3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a document with commented config files. We made the config files available standalone (ready to be run) and subsequently focused more and more on maintaining the configuration files and add more features and then let the comments/document come afterwards. Keeping everything in sync was a problem. We had early decided to keep everything in one common structure and let each config build on each other (to incrementally add functionality). This helped us in making sure everything worked and people didn't have to integrate small examples into one big themselves.
Our biggest problem was to keep adding features and making sure that we updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system
(http://www.iptel.org/ser/doc/buildsystem) which keeps the configuration files WITH comments and allows auto-generation of the commented config ready for inclusion in SER - Getting Started document
In creating the build system, I put emphasize on the capability to maintain different configuration sets (called feature packages, ex. gettingstarted) composed of different feature sets (helloworld, auth, natrtpproxy etc), each consisting of a set of features (natdetection, natmangling, etc). The configuration files are easier to maintain and as added value, people can automatically generate their config file based on an example with correct IP address, port etc. (BTW, I work on allowing people to generate their config files directly from from iptel.org)
This may sound complicated, but I believe a quick look at the doc (http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the current ser.cfg config with the optimized NAT example, and we will try to use that config as a starting point for a new NAT SER - Getting Started configuration file.
I don't think everything should go into the SER - Getting Started feature package (though we should at least avoid creating two versions of exactly the same functionality), but I hope you will spend some minutes to see how a new feature package in the build system can help your goals. I will of course be happy to assist you (as I have waited to see interest before documenting creating new feature packages). g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up: Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features"
into one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Greger,
thanks for your detailed answer. I have absolutely no problem with using the new m4 buildsystem. But correct me if I'm wrong, but AFAIK it is not yet ready to be used, or? And Jiri keeps pushing me that these configuration examples are important for the Ottendorf release :-)
So I would propose that I'll keep on putting new config examples into the etc directory on the CVS until the new buildsystem is ready to be used. And then I will transfer my configurations to that system.
Greetings Nils
On Monday 14 May 2007 13:04:23 Greger V. Teigre wrote:
Hi Nils, Good initiative! I think we need to coordinate our efforts so we avoid duplicate work. ONsip.org and iptel.org merged partly because we wanted to align the SER
- Getting Started configuration files with the development of SER. As
you probably have seen on the lists, the intention is to add the document and the config files to the cvs (SER 2.0). Most beginners of SER (and many OpenSER beginners) start out with the SER - Getting Started document and configs. From what I have seen, there are now many, many production configs out there using the basic structure from the getting started files.
We have learned quite a lot about maintaining example configuration files:
- People need small pieces in order to understand how each feature is
implemented 2. Without an expert pre-integrating configs/features, many/most? people struggle to integrate a feature into another config 3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a document with commented config files. We made the config files available standalone (ready to be run) and subsequently focused more and more on maintaining the configuration files and add more features and then let the comments/document come afterwards. Keeping everything in sync was a problem. We had early decided to keep everything in one common structure and let each config build on each other (to incrementally add functionality). This helped us in making sure everything worked and people didn't have to integrate small examples into one big themselves.
Our biggest problem was to keep adding features and making sure that we updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system (http://www.iptel.org/ser/doc/buildsystem)
which keeps the configuration files WITH comments and allows auto-generation of the commented config ready for inclusion in SER - Getting Started document
In creating the build system, I put emphasize on the capability to maintain different configuration sets (called feature packages, ex. gettingstarted) composed of different feature sets (helloworld, auth, natrtpproxy etc), each consisting of a set of features (natdetection, natmangling, etc). The configuration files are easier to maintain and as added value, people can automatically generate their config file based on an example with correct IP address, port etc. (BTW, I work on allowing people to generate their config files directly from from iptel.org)
This may sound complicated, but I believe a quick look at the doc (http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the current ser.cfg config with the optimized NAT example, and we will try to use that config as a starting point for a new NAT SER - Getting Started configuration file.
I don't think everything should go into the SER - Getting Started feature package (though we should at least avoid creating two versions of exactly the same functionality), but I hope you will spend some minutes to see how a new feature package in the build system can help your goals. I will of course be happy to assist you (as I have waited to see interest before documenting creating new feature packages). g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into
one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
It's ready to be used :-) I'll try to prioritize the how-to for new feature packages and I will commit it to cvs trunk. If you like, I can add the first example for you as a template. g-)
------- Original message ------- From: Nils Ohlmeier nils@iptel.org Cc: greger@teigre.com, serdev@iptel.org, serusers@iptel.org Sent: 14.5.'07, 16:36
Hi Greger,
thanks for your detailed answer. I have absolutely no problem with using the new m4 buildsystem. But correct me if I'm wrong, but AFAIK it is not yet ready to be used, or? And Jiri keeps pushing me that these configuration examples are important for the Ottendorf release :-)
So I would propose that I'll keep on putting new config examples into the etc directory on the CVS until the new buildsystem is ready to be used. And then I will transfer my configurations to that system.
Greetings Nils
On Monday 14 May 2007 13:04:23 Greger V. Teigre wrote:
Hi Nils, Good initiative! I think we need to coordinate our efforts so we avoid duplicate work. ONsip.org and iptel.org merged partly because we wanted to align the SER
- Getting Started configuration files with the development of SER. As
you probably have seen on the lists, the intention is to add the document and the config files to the cvs (SER 2.0). Most beginners of SER (and many OpenSER beginners) start out with the SER - Getting Started document and configs. From what I have seen, there are now many, many production configs out there using the basic structure from the getting started files.
We have learned quite a lot about maintaining example configuration files:
- People need small pieces in order to understand how each feature is
implemented 2. Without an expert pre-integrating configs/features, many/most? people struggle to integrate a feature into another config 3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a document with commented config files. We made the config files available standalone (ready to be run) and subsequently focused more and more on maintaining the configuration files and add more features and then let the comments/document come afterwards. Keeping everything in sync was a problem. We had early decided to keep everything in one common structure and let each config build on each other (to incrementally add functionality). This helped us in making sure everything worked and people didn't have to integrate small examples into one big themselves.
Our biggest problem was to keep adding features and making sure that we updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system (http://www.iptel.org/ser/doc/buildsystem)
which keeps the configuration files WITH comments and allows auto-generation of the commented config ready for inclusion in SER - Getting Started document
In creating the build system, I put emphasize on the capability to maintain different configuration sets (called feature packages, ex. gettingstarted) composed of different feature sets (helloworld, auth, natrtpproxy etc), each consisting of a set of features (natdetection, natmangling, etc). The configuration files are easier to maintain and as added value, people can automatically generate their config file based on an example with correct IP address, port etc. (BTW, I work on allowing people to generate their config files directly from from iptel.org)
This may sound complicated, but I believe a quick look at the doc (http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the current ser.cfg config with the optimized NAT example, and we will try to use that config as a starting point for a new NAT SER - Getting Started configuration file.
I don't think everything should go into the SER - Getting Started feature package (though we should at least avoid creating two versions of exactly the same functionality), but I hope you will spend some minutes to see how a new feature package in the build system can help your goals. I will of course be happy to assist you (as I have waited to see interest before documenting creating new feature packages). g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into
one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi
its need both, one big example file
and seperated example file each module config files should be good idea
ram
Hi Nils
It would be very useful to have 1 (one) big configuration file implementing a superset of the most popular features (nathelper, tls, presence etc..) and split into logical parts, so people can remove/disable unwanted features.
If you can publish the ser.cfg for the SER running on sip:iptel.org that would be even better.. Nothing beats a working config from long-term deployment.
I am currently also assisting Greger now, to get the ser.cfg build system up2dated with working configuration files..
/alfred
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
As for me I am largely in favor of having a kind of config-file "super-store" or "exchange" -- it appears there is never enough of those :-)
-jiri
At 18:01 14/05/2007, Alfred E. Heggestad wrote:
Hi Nils
It would be very useful to have 1 (one) big configuration file implementing a superset of the most popular features (nathelper, tls, presence etc..) and split into logical parts, so people can remove/disable unwanted features.
If you can publish the ser.cfg for the SER running on sip:iptel.org that would be even better.. Nothing beats a working config from long-term deployment.
I am currently also assisting Greger now, to get the ser.cfg build system up2dated with working configuration files..
/alfred
Nils Ohlmeier wrote:
Hello everybody, as we want to provide more examples for the configuration the following the question came up: Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know what you prefer or if you see other options. Thanks Nils _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
-- Jiri Kuthan http://iptel.org/~jiri/
With the named routes it wouldn't be too difficult to follow a big config file...
just my 0.02, sam.
2007/5/14, Jiri Kuthan jiri@iptel.org:
As for me I am largely in favor of having a kind of config-file "super-store" or "exchange" -- it appears there is never enough of those :-)
-jiri
At 18:01 14/05/2007, Alfred E. Heggestad wrote:
Hi Nils
It would be very useful to have 1 (one) big configuration file
implementing
a superset of the most popular features (nathelper, tls, presence etc..) and split into logical parts, so people can remove/disable unwanted
features.
If you can publish the ser.cfg for the SER running on sip:iptel.org that
would
be even better.. Nothing beats a working config from long-term
deployment.
I am currently also assisting Greger now, to get the ser.cfg build system up2dated with working configuration files..
/alfred
Nils Ohlmeier wrote:
Hello everybody, as we want to provide more examples for the configuration the following
the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features"
into one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I
would like to know what you prefer or if you see other options.
Thanks Nils _______________________________________________ Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
-- Jiri Kuthan http://iptel.org/~jiri/
Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
-
Alfred E. Heggestad -
flavio -
Greger V. Teigre -
Greger Viken Teigre
-
Jiri Kuthan -
Nils Ohlmeier -
ram -
samuel -
SIP