Permalink
Browse files

Add .html files (generated from their .pod files)

  • Loading branch information...
1 parent 220974a commit 8f4a115c36195341dda1f02a84d65db5a5b5260d @ranguard ranguard committed Mar 17, 2012
Showing with 91 additions and 242 deletions.
  1. +54 −144 source/archive/rfc/meta/rfc-format.html
  2. +37 −98 source/archive/rfc/meta/rfc-sample.html
@@ -1,147 +1,57 @@
-<HTML>
-<HEAD>
-<TITLE>RFCs</TITLE>
-<LINK REV="made" HREF="mailto:ask@tmtowtdi.perl.org">
-</HEAD>
-
-<BODY>
-
-<!-- INDEX BEGIN -->
-
-<UL>
-
- <LI><A HREF="#RFCs">RFCs</A>
- <LI><A HREF="#Format">Format</A>
- <UL>
-
- <LI><A HREF="#TITLE">TITLE</A>
- <LI><A HREF="#VERSION">VERSION</A>
- <LI><A HREF="#ABSTRACT">ABSTRACT</A>
- <LI><A HREF="#DESCRIPTION">DESCRIPTION</A>
- <LI><A HREF="#IMPLEMENTATION">IMPLEMENTATION</A>
- <LI><A HREF="#REFERENCES">REFERENCES</A>
- <LI><A HREF="#STATUS">STATUS</A>
- </UL>
-
- <LI><A HREF="#Submitting">Submitting</A>
-</UL>
-<!-- INDEX END -->
-
-<HR>
-<P>
-<H1><A NAME="RFCs">RFCs</A></H1>
-<P>
-Larry Wall will decide the changes to make for perl6 based on our
-suggestions. To make life easy for him, we should put some effort into our
-suggestions. RFCs are intended to be focus discussion on something that
-will be useful to Larry when he makes his decisions.
-
-<P>
-This format was last changed July 31, 2000.
-
-<P>
-<HR>
-<H1><A NAME="Format">Format</A></H1>
-<P>
-RFCs are written in POD. <EM>rfc-sample.pod</EM> is a sample. The important sections are: TITLE, VERSION, ABSTRACT,
-DESCRIPTION, IMPLEMENTATION, and REFERENCES. An optional section is STATUS.
-
-<P>
-A description of each section follows:
-
-<P>
-<HR>
-<H2><A NAME="TITLE">TITLE</A></H2>
-<P>
-One line, describing the proposed new feature or change.
-
-<P>
-<HR>
-<H2><A NAME="VERSION">VERSION</A></H2>
-<P>
-Metadata information: Maintainer, Date, Version, Mailing List, and Number.
-
-<UL>
-<LI>
-<P>
-Maintainer. The name and email address of the person currently maintaining
-the RFC.
-
-<LI>
-<P>
-Date. The date of the most recent release.
-
-<LI>
-<P>
-Version. An integer version number. First version is 1.
-
-<LI>
-<P>
-Mailing List. The mailing list on which discussion about this feature or
-change has taken place.
-
-<LI>
-<P>
-Number. Unique RFC number, assigned by the librarian.
-
-</UL>
-<P>
-Here is an example:
-
-<P>
-<PRE> =head1 VERSION
-</PRE>
-<P>
-<PRE> Maintainer: Nathan Torkington &lt;gnat@frii.com&gt;
+[% setvar title RFCs %]
+<div class='pod'>
+<a name='RFCs'></a><h1>RFCs</h1>
+<p>Larry Wall will decide the changes to make for perl6 based on our
+suggestions. To make life easy for him, we should put some effort
+into our suggestions. RFCs are intended to be focus discussion on
+something that will be useful to Larry when he makes his decisions.</p>
+<p>This format was last changed July 31, 2000.</p>
+<a name='Format'></a><h1>Format</h1>
+<p>RFCs are written in POD. <i><a href='http://search.cpan.org/perldoc?rfc-sample.pod'>rfc-sample.pod</a></i> is a sample. The
+important sections are: TITLE, VERSION, ABSTRACT, DESCRIPTION,
+IMPLEMENTATION, and REFERENCES. An optional section is STATUS.</p>
+<p>A description of each section follows:</p>
+<a name='TITLE'></a><h2>TITLE</h2>
+<p>One line, describing the proposed new feature or change.</p>
+<a name='VERSION'></a><h2>VERSION</h2>
+<p>Metadata information: Maintainer, Date, Version, Mailing List, and
+Number.</p>
+<ul>
+<li><a name='Maintainer. The name and email address of the person currently maintaining the RFC.'></a>Maintainer. The name and email address of the person currently
+maintaining the RFC.</li>
+<li><a name='Date. The date of the most recent release.'></a>Date. The date of the most recent release.</li>
+<li><a name='Version. An integer version number. First version is 1.'></a>Version. An integer version number. First version is 1.</li>
+<li><a name='Mailing List. The mailing list on which discussion about this feature or change has taken place.'></a>Mailing List. The mailing list on which discussion about this feature
+or change has taken place.</li>
+<li><a name='Number. Unique RFC number, assigned by the librarian.'></a>Number. Unique RFC number, assigned by the librarian.</li>
+</ul>
+<p>Here is an example:</p>
+<pre> =head1 VERSION
+
+ Maintainer: Nathan Torkington &lt;<a href='mailto:gnat@frii.com'>gnat@frii.com</a>&gt;
Date: 30 Jul 2000
Version: 2
Mailing List: perl6-internals
- Number: 1
-</PRE>
-<P>
-<HR>
-<H2><A NAME="ABSTRACT">ABSTRACT</A></H2>
-<P>
-One or two paragraph summary of the problem and proposed solutions, or
-feature and probable implementations.
-
-<P>
-<HR>
-<H2><A NAME="DESCRIPTION">DESCRIPTION</A></H2>
-<P>
-Detailed discussion of the problem or new feature.
-
-<P>
-<HR>
-<H2><A NAME="IMPLEMENTATION">IMPLEMENTATION</A></H2>
-<P>
-Discussion of the possible implementations. This doesn't have to be
-completely defined down to the <CODE>char *</CODE>, instead enough to show that it can be done.
-
-<P>
-<HR>
-<H2><A NAME="REFERENCES">REFERENCES</A></H2>
-<P>
-A list of pointers to other documentation relevant to the topic. This could
-be other RFCs, internet standards, existing Perl or operating-system
-documentation, books, and so on.
-
-<P>
-<HR>
-<H2><A NAME="STATUS">STATUS</A></H2>
-<P>
-Once an RFC is retired, the STATUS section is used to say why and how the
-RFC is dead.
-
-<P>
-<HR>
-<H1><A NAME="Submitting">Submitting</A></H1>
-<P>
-Mail the RFC to <CODE>perl6-rfc@perl.org</CODE>. It will be assigned a number if it doesn't already have one, then posted
-to the
-<CODE>perl6-announce</CODE> mailing list, as well as the list in the <CODE>Mailing
-list</CODE> metadata. They will also be archived at <CODE>http://dev.perl.org</CODE>.
-
-</BODY>
-
-</HTML>
+ Number: 1</pre>
+<a name='ABSTRACT'></a><h2>ABSTRACT</h2>
+<p>One or two paragraph summary of the problem and proposed solutions,
+or feature and probable implementations.</p>
+<a name='DESCRIPTION'></a><h2>DESCRIPTION</h2>
+<p>Detailed discussion of the problem or new feature.</p>
+<a name='IMPLEMENTATION'></a><h2>IMPLEMENTATION</h2>
+<p>Discussion of the possible implementations. This doesn't have to
+be completely defined down to the <code>char *</code>, instead enough to show
+that it can be done.</p>
+<a name='REFERENCES'></a><h2>REFERENCES</h2>
+<p>A list of pointers to other documentation relevant to the topic. This
+could be other RFCs, internet standards, existing Perl or
+operating-system documentation, books, and so on.</p>
+<a name='STATUS'></a><h2>STATUS</h2>
+<p>Once an RFC is retired, the STATUS section is used to say why and how
+the RFC is dead.</p>
+<a name='Submitting'></a><h1>Submitting</h1>
+<p>Mail the RFC to <code>perl6-rfc@perl.org</code>. It will be assigned a
+number if it doesn't already have one, then posted to the
+<code>perl6-announce</code> mailing list, as well as the list in the <code>Mailing
+list</code> metadata. They will also be archived at <code><a href='http://dev.perl.org' target='_blank'>dev.perl.org</a></code>.</p>
+</div>
@@ -1,101 +1,40 @@
-<HTML>
-<HEAD>
-<TITLE>TITLE</TITLE>
-<LINK REV="made" HREF="mailto:ask@tmtowtdi.perl.org">
-</HEAD>
-
-<BODY>
-
-<!-- INDEX BEGIN -->
-
-<UL>
-
- <LI><A HREF="#TITLE">TITLE</A>
- <LI><A HREF="#VERSION">VERSION</A>
- <LI><A HREF="#ABSTRACT">ABSTRACT</A>
- <LI><A HREF="#DESCRIPTION">DESCRIPTION</A>
- <LI><A HREF="#IMPLEMENTATION">IMPLEMENTATION</A>
- <UL>
-
- <LI><A HREF="#Checkpointing">Checkpointing</A>
- <LI><A HREF="#Event_loop">Event loop</A>
- </UL>
-
- <LI><A HREF="#REFERENCES">REFERENCES</A>
-</UL>
-<!-- INDEX END -->
-
-<HR>
-<P>
-<H1><A NAME="TITLE">TITLE</A></H1>
-<P>
-Safe signal-handling for Perl.
-
-<P>
-<HR>
-<H1><A NAME="VERSION">VERSION</A></H1>
-<P>
-<PRE> Maintainer: Nathan Torkington &lt;gnat@frii.com&gt;
+[% setvar title Safe signal-handling for Perl. %]
+<div class='pod'>
+<a name='TITLE'></a><h1>TITLE</h1>
+<p>Safe signal-handling for Perl.</p>
+<a name='VERSION'></a><h1>VERSION</h1>
+<pre> Maintainer: Nathan Torkington &lt;<a href='mailto:gnat@frii.com'>gnat@frii.com</a>&gt;
Date: 30 Jul 2000
Version: 2
Mailing List: perl6-internals
- Number: 1
-</PRE>
-<P>
-<HR>
-<H1><A NAME="ABSTRACT">ABSTRACT</A></H1>
-<P>
-The signal-handling mechanism in Perl 5 is not safe, but should be. The two
-main candidates for implementation are delayed delivery via checkpointing
-and the event loop.
-
-<P>
-<HR>
-<H1><A NAME="DESCRIPTION">DESCRIPTION</A></H1>
-<P>
-Signals may leave Perl in an inconsistent state, so that an inocuous
-<CODE>print</CODE> in a signal handler might trigger a core-dump. This is referred to as
-``unsafe signals''.
-
-<P>
-Signal safety is crucial. Signals are how timeouts, child process deaths,
-and many other important things are conveyed to a program. Many programs
-with operating-system interaction require signals, and core-dumps are
-unacceptable.
-
-<P>
-<HR>
-<H1><A NAME="IMPLEMENTATION">IMPLEMENTATION</A></H1>
-<P>
-There are two choices for implementation: checkpointing, and event loop.
-[Editor's note: the other RFC I refer to is fictitious]
-
-<P>
-<HR>
-<H2><A NAME="Checkpointing">Checkpointing</A></H2>
-<P>
-If the Perl interpreter checkpointed itself at internally consistent
-states, those states could be used to deliver signals. This would delay
-delivery, however, and the semantics of delayed signals might make some
-programs impossible to write correctly.
-
-<P>
-<HR>
-<H2><A NAME="Event_loop">Event loop</A></H2>
-<P>
-RFC 6 describes a desired event loop mechanism. If the existing signal
-mechanism (%SIG) were dropped, signals could simply become events that a
-program might or might not respond to. This would be a new model of signal
-handling which would make it difficult to reuse algorithms and code for
-systems programming from C.
-
-<P>
-<HR>
-<H1><A NAME="REFERENCES">REFERENCES</A></H1>
-<P>
-<PRE> RFC 6: &quot;Standard Event Loop&quot;
- perlvar manpage for discussion of %SIG
-</PRE>
-</BODY>
-
-</HTML>
+ Number: 1</pre>
+<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
+<p>The signal-handling mechanism in Perl 5 is not safe, but should be.
+The two main candidates for implementation are delayed delivery via
+checkpointing and the event loop.</p>
+<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
+<p>Signals may leave Perl in an inconsistent state, so that an inocuous
+<code>print</code> in a signal handler might trigger a core-dump. This is
+referred to as &quot;unsafe signals&quot;.</p>
+<p>Signal safety is crucial. Signals are how timeouts, child process
+deaths, and many other important things are conveyed to a program.
+Many programs with operating-system interaction require signals,
+and core-dumps are unacceptable.</p>
+<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
+<p>There are two choices for implementation: checkpointing, and event
+loop. [Editor's note: the other RFC I refer to is fictitious]</p>
+<a name='Checkpointing'></a><h2>Checkpointing</h2>
+<p>If the Perl interpreter checkpointed itself at internally consistent
+states, those states could be used to deliver signals. This would
+delay delivery, however, and the semantics of delayed signals might
+make some programs impossible to write correctly.</p>
+<a name='Event loop'></a><h2>Event loop</h2>
+<p>RFC 6 describes a desired event loop mechanism. If the existing
+signal mechanism (%SIG) were dropped, signals could simply become
+events that a program might or might not respond to. This would be a
+new model of signal handling which would make it difficult to reuse
+algorithms and code for systems programming from C.</p>
+<a name='REFERENCES'></a><h1>REFERENCES</h1>
+<pre> RFC 6: &quot;Standard Event Loop&quot;
+ perlvar manpage for discussion of %SIG</pre>
+</div>

0 comments on commit 8f4a115

Please sign in to comment.