1 # requirements.pod: The pre-planning document
2 # Copyright (C) 2002 Stanislav Sinyagin
4 # This program is free software; you can redistribute it and/or modify
5 # it under the terms of the GNU General Public License as published by
6 # the Free Software Foundation; either version 2 of the License, or
7 # (at your option) any later version.
9 # This program is distributed in the hope that it will be useful,
10 # but WITHOUT ANY WARRANTY; without even the implied warranty of
11 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
12 # GNU General Public License for more details.
14 # You should have received a copy of the GNU General Public License
15 # along with this program; if not, write to the Free Software
16 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
18 # $Id: reqs.0.1.pod,v 1.1 2010-12-27 00:04:36 ivan Exp $
19 # Stanislav Sinyagin <ssinyagin@yahoo.com>
23 =head1 RRFW Requirements Version 0.1
25 Date: Jun 29 2003; Last revised: Aug 05 2003
27 In this article, I describe the important changes that are planned
28 for RRFW version 0.1.X.
30 =head1 Independent datasource trees
32 As noted by many users, RRFW lacks the scalability when the number of
33 network devices is more than 100. The XML compiler takes minutes to
34 process the configuration, and the Collector process initialization time
37 Christian Schnidrig E<lt>christian.schnidrig@gmx.chE<gt> has proposed
38 a solution to split the database into several subsystems, each
39 being compiled separately, and with separate collector process.
40 In his concept, there is a "global" datasource tree, and
41 "subsystem" trees, each making a subset of global datasource nodes.
43 I propose to have a number of independent datasource trees, without
44 any superset. This would ease the administrator's work, and add more
47 =head2 Changes in rrfw-siteconfig.pl
49 Instead of C<@RRFW::Global::xmlFiles>, the following hash will contain
50 the information about the trees:
52 %RRFW::Global::treeConfig = (
54 'description' => 'The First Tree',
55 'xmlfiles' => ['a1.xml', 'a2.xml', 'a3.xml'],
56 'run' => { 'collector' => 1, 'monitor' => 1 } },
58 'description' => 'The Second Tree',
59 'xmlfiles' => ['b1.xml', 'b2.xml'],
63 In this hash, the keys give the tree names, I<xmlfiles> points to an array
64 of source XML files, I<run> points to the names of the daemons that
65 would be automatically launched for the tree.
67 Two additional arrays: C<@RRFW::Global::xmlAlwaysIncludeFirst> and
68 C<@RRFW::Global::xmlAlwaysIncludeLast> will give a list of source XML
69 files that are included in every tree, in the beginning or in the end of
72 =head2 ConfigTree object internals
74 There will be no such thing as globalInstance. All methods and procedures
75 that need to reference the current ConfigTree object will have it as
78 C<RRFW::ConfigTree::new()> will have a mandatory argument "TreeName".
80 =head2 Database structure
82 All datasource trees will share one BerkeleyDB environment. The
83 BDB environment home directory will stay the same, defined by I<dbhome>
86 For each tree, the database files will be placed in a separate subdirectory
87 of a subdirectory of I<dbhome>.
92 All relevant command-line executables will support the following
97 =item * --tree <tree_name>
99 Specifies the datasource tree for processing;
103 If applicable, performs the operation on all available trees.
107 When in verbose mode (B<--verbose>), the command-line programs must
108 print the tree names they operate with.
110 The web interface will take the PATH_INFO string as the tree name.
111 For mod_perl handler, it will be also possible to prohibit
112 PATH_INFO selection, and to configure the tree name in Apache
115 When no PATH_INFO is given to the web interface handler,
116 a special superlevel menu may be shown with the list of available trees.
118 It will also be possible to specify tree-specific renderer attributes, like
119 C<%RRFW::Renderer::styling>, C<$RRFW::Renderer::companyName>, etc.
121 B<Plain CGI interface will not be supported> As Renderer gets more complex,
122 CGI initialization time will increase. Also it will become harder to support
123 two user interfaces with similar functionality.
126 =head2 Daemons launch master
128 There will be a master process that will launch collector and monitor
129 daemons for each tree. It will be configurable from a separate file,
130 specifying the daemons and execution parameters for each tree.
132 The master process will watch the child processes and issue warnings in the
133 events of child process termination.
135 Stopping the master process will stop all child daemons gracefully.
138 =head1 Separate database for non-datasource objects
140 In RRFW version 0.0.X, all the parameters for datasources, views,
141 monitors, and tokensets are stored in F<configuration.db> database.
143 As proposed by Christian Schnidrig, storing all non-datasource
144 objects information in a separate database would improve the scalability.
146 In RRFW version 0.1.X, datasource parameters will be stored in
147 F<ds_config.db>, and all other object's parameters in F<other_config.db>.
149 The XML compiler will have a new option, B<--nods>, which disables
150 processing of E<lt>datasourcesE<gt> elements in the input XML files.
152 In addition to C<ConfigurationReady> flag, there will be a flag that indicates
153 the readiness of datasource tree only.
155 All these measures will allow faster administration and testing of
156 non-datasource objects, and will prevent the collector from unneeded
160 =head1 User privileges
162 User privileges will apply to the tree level: across one datasource tree
163 a given user will have uniform privileges.
165 Each user belongs to one or more groups. Privileges are assigned to
166 groups only, not to individual users. Groups are one-level deep: they
167 consist of users only. Probably in the future groups will consist
170 In the beginning, only one privilege will be implemented: I<DisplayTree>.
171 The design should be flexible enough to add more privileges in the future.
172 Examples: I<GenerateReport>, I<Debug>, I<ScheduleTask>, and so on.
174 Privileges maintenance interface will include a command-line utility.
175 In the future, a web interface is also possible. In this case, a new
176 privilege will be added: I<EditPrivileges>.
178 Privileges editor will include the following functions:
182 =item * add/delete group
184 =item * add/delete user
186 =item * change user password
188 =item * add/delete user membership in a group
190 =item * edit privileges for groups and trees
192 =item * list group members
194 =item * list groups a user belongs to
196 =item * list privileges for a given group or user
198 =item * list privileges and groups (or users) for a given tree
200 =item * export/import the privileges database to/from XML
204 Privileges logics implementation must be separate from the database backend.
205 At first, BerkeleyDB backend will be supported. In the future, LDAP
210 Copyright (c) 2003 Stanislav Sinyagin ssinyagin@yahoo.com