+# requirements.pod: The pre-planning document
+# Copyright (C) 2002 Stanislav Sinyagin
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
+
+# $Id: reqs.0.1.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $
+# Stanislav Sinyagin <ssinyagin@yahoo.com>
+#
+#
+
+=head1 RRFW Requirements Version 0.1
+
+Date: Jun 29 2003; Last revised: Aug 05 2003
+
+In this article, I describe the important changes that are planned
+for RRFW version 0.1.X.
+
+=head1 Independent datasource trees
+
+As noted by many users, RRFW lacks the scalability when the number of
+network devices is more than 100. The XML compiler takes minutes to
+process the configuration, and the Collector process initialization time
+is too long.
+
+Christian Schnidrig E<lt>christian.schnidrig@gmx.chE<gt> has proposed
+a solution to split the database into several subsystems, each
+being compiled separately, and with separate collector process.
+In his concept, there is a "global" datasource tree, and
+"subsystem" trees, each making a subset of global datasource nodes.
+
+I propose to have a number of independent datasource trees, without
+any superset. This would ease the administrator's work, and add more
+security.
+
+=head2 Changes in rrfw-siteconfig.pl
+
+Instead of C<@RRFW::Global::xmlFiles>, the following hash will contain
+the information about the trees:
+
+ %RRFW::Global::treeConfig = (
+ 'tree_A' => {
+ 'description' => 'The First Tree',
+ 'xmlfiles' => ['a1.xml', 'a2.xml', 'a3.xml'],
+ 'run' => { 'collector' => 1, 'monitor' => 1 } },
+ 'tree_B' => {
+ 'description' => 'The Second Tree',
+ 'xmlfiles' => ['b1.xml', 'b2.xml'],
+ 'run' => {} }
+ );
+
+In this hash, the keys give the tree names, I<xmlfiles> points to an array
+of source XML files, I<run> points to the names of the daemons that
+would be automatically launched for the tree.
+
+Two additional arrays: C<@RRFW::Global::xmlAlwaysIncludeFirst> and
+C<@RRFW::Global::xmlAlwaysIncludeLast> will give a list of source XML
+files that are included in every tree, in the beginning or in the end of
+the XML files list.
+
+=head2 ConfigTree object internals
+
+There will be no such thing as globalInstance. All methods and procedures
+that need to reference the current ConfigTree object will have it as
+argument.
+
+C<RRFW::ConfigTree::new()> will have a mandatory argument "TreeName".
+
+=head2 Database structure
+
+All datasource trees will share one BerkeleyDB environment. The
+BDB environment home directory will stay the same, defined by I<dbhome>
+config variable.
+
+For each tree, the database files will be placed in a separate subdirectory
+of a subdirectory of I<dbhome>.
+
+
+=head2 User interface
+
+All relevant command-line executables will support the following
+options:
+
+=over 4
+
+=item * --tree <tree_name>
+
+Specifies the datasource tree for processing;
+
+=item * --all
+
+If applicable, performs the operation on all available trees.
+
+=back
+
+When in verbose mode (B<--verbose>), the command-line programs must
+print the tree names they operate with.
+
+The web interface will take the PATH_INFO string as the tree name.
+For mod_perl handler, it will be also possible to prohibit
+PATH_INFO selection, and to configure the tree name in Apache
+configuration.
+
+When no PATH_INFO is given to the web interface handler,
+a special superlevel menu may be shown with the list of available trees.
+
+It will also be possible to specify tree-specific renderer attributes, like
+C<%RRFW::Renderer::styling>, C<$RRFW::Renderer::companyName>, etc.
+
+B<Plain CGI interface will not be supported> As Renderer gets more complex,
+CGI initialization time will increase. Also it will become harder to support
+two user interfaces with similar functionality.
+
+
+=head2 Daemons launch master
+
+There will be a master process that will launch collector and monitor
+daemons for each tree. It will be configurable from a separate file,
+specifying the daemons and execution parameters for each tree.
+
+The master process will watch the child processes and issue warnings in the
+events of child process termination.
+
+Stopping the master process will stop all child daemons gracefully.
+
+
+=head1 Separate database for non-datasource objects
+
+In RRFW version 0.0.X, all the parameters for datasources, views,
+monitors, and tokensets are stored in F<configuration.db> database.
+
+As proposed by Christian Schnidrig, storing all non-datasource
+objects information in a separate database would improve the scalability.
+
+In RRFW version 0.1.X, datasource parameters will be stored in
+F<ds_config.db>, and all other object's parameters in F<other_config.db>.
+
+The XML compiler will have a new option, B<--nods>, which disables
+processing of E<lt>datasourcesE<gt> elements in the input XML files.
+
+In addition to C<ConfigurationReady> flag, there will be a flag that indicates
+the readiness of datasource tree only.
+
+All these measures will allow faster administration and testing of
+non-datasource objects, and will prevent the collector from unneeded
+interruptions.
+
+
+=head1 User privileges
+
+User privileges will apply to the tree level: across one datasource tree
+a given user will have uniform privileges.
+
+Each user belongs to one or more groups. Privileges are assigned to
+groups only, not to individual users. Groups are one-level deep: they
+consist of users only. Probably in the future groups will consist
+of groups too.
+
+In the beginning, only one privilege will be implemented: I<DisplayTree>.
+The design should be flexible enough to add more privileges in the future.
+Examples: I<GenerateReport>, I<Debug>, I<ScheduleTask>, and so on.
+
+Privileges maintenance interface will include a command-line utility.
+In the future, a web interface is also possible. In this case, a new
+privilege will be added: I<EditPrivileges>.
+
+Privileges editor will include the following functions:
+
+=over 4
+
+=item * add/delete group
+
+=item * add/delete user
+
+=item * change user password
+
+=item * add/delete user membership in a group
+
+=item * edit privileges for groups and trees
+
+=item * list group members
+
+=item * list groups a user belongs to
+
+=item * list privileges for a given group or user
+
+=item * list privileges and groups (or users) for a given tree
+
+=item * export/import the privileges database to/from XML
+
+=back
+
+Privileges logics implementation must be separate from the database backend.
+At first, BerkeleyDB backend will be supported. In the future, LDAP
+backend is possible.
+
+=head1 Author
+
+Copyright (c) 2003 Stanislav Sinyagin ssinyagin@yahoo.com
projects / freeside.git / blobdiff