diff options
| -rw-r--r-- | doc/features.html | 13 | ||||
| -rw-r--r-- | doc/version_naming.html | 61 |
2 files changed, 42 insertions, 32 deletions
diff --git a/doc/features.html b/doc/features.html index 725c3d7d..f451c857 100644 --- a/doc/features.html +++ b/doc/features.html @@ -43,7 +43,8 @@ is going on, you can also subscribe to the <a href="http://lists.adiscon.net/mai on a per selector-line basis<li> supports sub-configuration files, which can be automatically read from directories. Includes are specified in the main configuration file<li> - supports multiple actions per selector/filter condition</ul> + supports multiple actions per selector/filter condition<li> + MySQL functionality as a dynamically loadable plug-in</ul> <p> </p> <h2>Upcoming Features</h2> <p>The list below is something like a repository of ideas we'd like to @@ -57,7 +58,9 @@ soon to be implemented"), they will possibly be migrated to this list here at some time moved back to the sourceforge tracker.</p> <ul> <li>create a plug-in-interface - we are very close to this. A neat interface is - already used internally for output modules.<li>implement native email-functionality in + already used internally for output modules and the MySQL module already + works as a plug-in. However, no interface defintion is yet formally + published.<li>implement native email-functionality in selector (probably best done as a plug-in)<li>port it to more *nix variants (eg AIX and HP UX) - this needs volunteers with access to those machines and knowledge<li>provide an on-disk queue for syslog messages; should be @@ -72,7 +75,11 @@ at some time moved back to the sourceforge tracker.</p> to do pcre<li>support for
<a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a>
as a sender - this is currently unlikely to happen, because there is no real demand for it. Any work on RFC 3195 has been suspend until we see some real interest in it. It is probably much better to use TCP-based syslog, - which is interoprable with a large number of applications.</ul> + which is interoperable with a large number of applications. You may also + read my blog post on the future of liblogging, which contains interesting + information about the + <a href="http://rgerhards.blogspot.com/2007/09/where-is-liblogging-heading-to.html"> + future of RFC 3195 in rsyslog</a>.</ul> <p>To see when each feature was added, see the <a href="http://www.rsyslog.com/Topic4.phtml">rsyslog change log</a> (online only).</p> diff --git a/doc/version_naming.html b/doc/version_naming.html index a1923fc2..31fe056e 100644 --- a/doc/version_naming.html +++ b/doc/version_naming.html @@ -1,30 +1,33 @@ -<html>
-<head>
-<title>rsyslog bugs and annoyances</title>
-</head>
-<body>
-<h1>Version Naming</h1>
-<p>This document briefly outlines the strategy for naming versions. It applies
-to versions 1.0.0 and above. Versions below that are all instable and have a
-different naming schema.</p>
-<p>The major version is incremented whenever a considerate, major features have
-been added. This is expected to happen quite infrequently.</p>
-<p>The minor version number is incremented whenever there is "sufficient need"
-(at the discretion of the developers). There is a notable difference between
-stable and instable branches. The <b>stable branch</b> always has a minor
-version number in the range from 0 to 9. It is expected that the stable branch
-will receive bug and security fixes only. So the range of minor version numbers
-should be quite sufficient.</p>
-<p>For the <b>instable branch</b>, minor version numbers always start at 10 and
-are incremented as needed (again, at the discretion of the developers). Here,
-new minor versions include both fixes as well as new features (hopefully most of
-the time). They are expected to be released quite often.</p>
-<p>The patch level (third number) is incremented whenever a really minor thing
-must be added to an existing version. This is expected to happen quite
-infrequently.</p>
-<p>In general, the instable branch carries all new development. Once it
-concludes with a sufficiently-enhanced, quite stable version, a new major stable
-version is assigned.</p>
-
-</body>
+<html> +<head> +<title>rsyslog bugs and annoyances</title> +</head> +<body> +<h1>Version Naming</h1> +<p>This document briefly outlines the strategy for naming versions. It applies +to versions 1.0.0 and above. Versions below that are all instable and have a +different naming schema.</p> +<p><b>Please note that version naming is currently being changed. There is a +<a href="http://rgerhards.blogspot.com/2007/08/on-rsyslog-versions.html">blog +post about future rsyslog versions</a>.</b></p> +<p>The major version is incremented whenever a considerate, major features have +been added. This is expected to happen quite infrequently.</p> +<p>The minor version number is incremented whenever there is "sufficient need" +(at the discretion of the developers). There is a notable difference between +stable and instable branches. The <b>stable branch</b> always has a minor +version number in the range from 0 to 9. It is expected that the stable branch +will receive bug and security fixes only. So the range of minor version numbers +should be quite sufficient.</p> +<p>For the <b>instable branch</b>, minor version numbers always start at 10 and +are incremented as needed (again, at the discretion of the developers). Here, +new minor versions include both fixes as well as new features (hopefully most of +the time). They are expected to be released quite often.</p> +<p>The patch level (third number) is incremented whenever a really minor thing +must be added to an existing version. This is expected to happen quite +infrequently.</p> +<p>In general, the instable branch carries all new development. Once it +concludes with a sufficiently-enhanced, quite stable version, a new major stable +version is assigned.</p> + +</body> </html>
\ No newline at end of file |