summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--doc/features.html13
-rw-r--r--doc/version_naming.html61
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>&nbsp;</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&quot;), 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.&nbsp; 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 &quot;sufficient need&quot;
-(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 &quot;sufficient need&quot;
+(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