-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdesign.txt
62 lines (50 loc) · 2.83 KB
/
design.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Browser compatibility:
FreeCMDB is written with a somewhat modern internet browser in. It
makes use of various features, such as SVG rendering and various CSS
selectors, that are only available in sane browsers. In other words,
FreeCMDB does not fully work with Internet Explorer. All major
functionality that uses such features must have a fallback, e.g. when
svg rendering is not provided, FreeCMDB falls back to a PNG. Minor
visual glitches and some reduced functionality will occur in older
browsers, though. Firefox 2.0 an onwards should work fine. Feedback on
other browsers is welcome.
Generally, FreeCMDB should be snappy, with a page rendering time of
0.1-0.2 seconds on the slowest pages using intermediate hardware and a
medium sized database. A normal page view performs 5-20 database
queries. Usually, PHP is the bottleneck, not the database. There are
several possible improvements, which could speed things up if
needed.
Database schema:
The schema is simple and mostly normalized. The exception is the
ci_log table. There are two exceptions:
Firstly, one would have to split the ci_log table into 4 different
tables to represent different change types. This may be done in a
later version.
Secondly, all column data is always stored in a varchar. In the case
of a dropdown list, what is stored is actually the id of the column
item in the ci_column_list table, ergo an integer that references
another table is stored in a unreferenced varchar column. The major
benefit of this construction is that it is possible to change column
types back and forth without destroying data. Nonetheless, this will
beobably be changed in a future version.
FreeCMDB usually avoids deleting data. When data, such as old CIs, is
removed, a flag on that line in the database is set, and nothing else
happens. This means that undelete functionality is relatively easy to
implement. It also means that the database will grow with use. This
should not be a big problem as deleting and creating CIs is not a
common operation. If this turns out to be a problem in the future, a
maximum time before deleted data is _truly_ removed may be
implemented. After this grace period, it would no longer be possible
to undelete items.
Plans for future work:
* Move image map to external page.
* Clever filtering interface for adding CIs.
* filtered graph to only show selected cis
* Add mandatory columns
* Use nmap to provide network information on CIs.
* Allow Anna to upload custom style sheets.
* Add more column types, e.g. list of links.
* Make it possible to reorder the columns in the display.
* Add possibility to remove some features for some CI types, e.g. CI types that are really assets should not have dependency tracking or RfC handling.
* License tracking, including showing when a software is used by more users than the license permits.
* Fix broken links and formating for truncated nodes