mirror of
https://github.com/rn10950/RetroZilla.git
synced 2024-11-14 03:30:17 +01:00
113 lines
4.4 KiB
HTML
113 lines
4.4 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
|
||
|
|
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
|
||
|
|
<title>Layout Detailed Design Template</title>
|
||
|
|
<meta name="author" content="Marc Attinasi (attinasi@netscape.com)">
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<h1><font color="#cc0000">Gecko Layout Detailed Design Document Template</font></h1>
|
||
|
|
[Use this template to start your detailed design. Replace items in square
|
||
|
|
brackets with the appropriate text for your component, class or system. Keep
|
||
|
|
in mind that this is just a general template intended for most designs.
|
||
|
|
Your specific design may require different organization or topics - the
|
||
|
|
goal is to provide detailed information about the software to the reader.]<br>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h1>[Component / Class Name] Detailed Design</h1>
|
||
|
|
|
||
|
|
<h2>Overview</h2>
|
||
|
|
[Introduce the scope of this design document: what is being documented here.
|
||
|
|
Provide a reference back to the High Level design(s) that correspond.]<br>
|
||
|
|
|
||
|
|
<hr width="100%" size="2">
|
||
|
|
<h2>[Class / Component A]</h2>
|
||
|
|
[Briefly refresh the reader with the purpose of the class or component.
|
||
|
|
Provide enough information to make accessible the following sections on the
|
||
|
|
public API, private methods and members, and algorithms. Bring up and tricky
|
||
|
|
or otherwise interesting relationships that will be detailed.]<br>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h3>Public API</h3>
|
||
|
|
[Show the public API for the component, as IDL, C++ header file, or as a
|
||
|
|
pseudo-code description. If using a source file, the comments in the
|
||
|
|
source file should cover most of the detail needed. If they do not, then add
|
||
|
|
that detail there. See the Overview document for more details on the
|
||
|
|
scope of information that should be presented.]<br>
|
||
|
|
|
||
|
|
<h3>Protected API</h3>
|
||
|
|
[If there is a protected API, list the methods and members and indicate
|
||
|
|
the responsibilities of the callers with respect o calling the base class,
|
||
|
|
enforcing base class invariants, etc.]<br>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h3>Implementation Notes</h3>
|
||
|
|
[The nasty details of the implementation get exposed here. This section
|
||
|
|
can be broken down into subsections as necessary, and should include details
|
||
|
|
of particularly important algorithms, performance characteristics or constraints,
|
||
|
|
memory usage, tricky ownership issues, and anything else that would make understanding
|
||
|
|
the implementation easier for the reader.]<br>
|
||
|
|
|
||
|
|
<h4>Algorithms</h4>
|
||
|
|
|
||
|
|
<h5>[Interesting Algorithm 1: The internally maintained sorted list]</h5>
|
||
|
|
[explain the nature of the algorithm, the reason it was chosen, the types
|
||
|
|
of input is is expected to operate on, etc. Annotated pseudo-code is a good
|
||
|
|
idea here, but actual code is often too detailed to b of much use by itself.
|
||
|
|
It the actual code is sufficient to understand it, then this subsection is
|
||
|
|
probably not needed.]<br>
|
||
|
|
|
||
|
|
<h5>[Interesting Algorithm 2: Handling overflow of the input buffer]</h5>
|
||
|
|
[your description here]<br>
|
||
|
|
|
||
|
|
<h4></h4>
|
||
|
|
|
||
|
|
<hr width="100%" size="2">
|
||
|
|
<h2>[Class / Component B]</h2>
|
||
|
|
[Repeat the structure for the next class or component.]<br>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<hr width="100%" size="2">
|
||
|
|
<h2>Cross-Component Algorithms</h2>
|
||
|
|
[specify the details of algorithms that cross a single component. refer
|
||
|
|
to each component, describe the flow of control, the responsibilities of each
|
||
|
|
component along the way, the error handling, the state-management if any,
|
||
|
|
and the expected results for a given input. Generally each of these algorithms
|
||
|
|
gets its own subsection.]<br>
|
||
|
|
|
||
|
|
<h3>[Turning a byte-stream into a fully parsed token-tree]</h3>
|
||
|
|
[Detailed description, pesudo-code, state transitions, etc.]<br>
|
||
|
|
|
||
|
|
<h3>[Managing updates to the the document]</h3>
|
||
|
|
[Detailed description, pesudo-code, state transitions, etc.]<br>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<hr width="100%" size="2">
|
||
|
|
<h2>Tech Notes</h2>
|
||
|
|
[This section contains links to tech notes related to the implementations
|
||
|
|
covered in this design. Tech Notes tend to be extremely specific, often
|
||
|
|
recipes for how to do something or how to fix a class of defects. If
|
||
|
|
the tech note is more general, it may be a good idea to move it into the Detailed
|
||
|
|
design itself.]<br>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>[<a href="link%20to%20tech%20note">Debugging buffer overflows</a>
|
||
|
|
]</li>
|
||
|
|
<li>[<a href="link%20to%20tech%20note">Adding new element or attribute
|
||
|
|
types</a>
|
||
|
|
]</li>
|
||
|
|
<li>[<a href="link%20to%20tech%20note">How To detect and fix problems
|
||
|
|
with the alignment of elements</a>
|
||
|
|
]</li>
|
||
|
|
<li>[<a href="link%20to%20tech%20note">Fix for Bug 666: ownership of tokens
|
||
|
|
was mistakenly transferred</a>
|
||
|
|
]</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
<br>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|